CPU Mining in Blockchain Environments

ABSTRACT

Blockchain environments may mix-and-match different encryption, difficulty, and/or proof-of-work schemes when mining blockchain transactions. Each encryption, difficulty, and/or proof-of-work scheme may be separate, stand-alone programs, files, or third-party services. Blockchain miners may be agnostic to a particular coin&#39;s or network&#39;s encryption, difficulty, and/or proof-of-work schemes, thus allowing any blockchain miner to process or mine data in multiple blockchains. GPUs, ASICs, and other specialized processing hardware components may be deterred by forcing cache misses, cache latencies, and processor stalls. Hashing, difficulty, and/or proof-of-work schemes require less programming code, consume less storage space/usage in bytes, and execute faster. Blockchain mining schemes may further randomize byte or memory block access, further improve cryptographic security.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims domestic benefit of U.S. ProvisionalApplication No. 63/061,372 filed Aug. 5, 2020 and is incorporated hereinby reference in its entirety. This patent application claims domesticbenefit of U.S. Provisional Application No. 62/962,486 filed Jan. 17,2020 and is incorporated herein by reference in its entirety. Thispatent application also claims domestic benefit of U.S. ProvisionalApplication No. 62/963,217 filed Jan. 20, 2020 and is incorporatedherein by reference in its entirety.

BACKGROUND

Today's blockchain processing consumes great hardware, network, andenergy resources. When Satoshi first proposed a cryptographicblockchain, so-called “miners” expended CPU time and electricity to mineblockchain data. The mining of blockchains was democratic, meaninganyone with a conventional CPU-based computer could process thecomplicated calculations required to embed a block of data on ablockchain. Soon, though, the miners realized that a graphics processingunit (or GPU) was much faster than a CPU and could be optimized to solvethe complicated calculations. Soon thereafter, most or all blockchainmining was performed by a specially programmed GPU computer, as aconventional CPU-based computer was comparatively too slow. Today,though, the miners use a specially-designed application-specificintegrated circuit (or ASIC), as ASICs are even faster than GPUs. TheseASIC computers are much faster at solving the complicated calculations,but the ASIC computers are very expensive and consume large amounts ofelectrical power. The ASIC computers are so cost prohibitive that,today, blockchain mining is largely undemocratic. Only a relativelysmall number of miners have access to the financial capital and toenergy sources to mine blockchains.

SUMMARY

Exemplary embodiments may separate hashing operations from difficultyand proof-of-work operations. When blockchain transactions or other datais processed or mined, encryption (such as a hashing algorithm) may be astand-alone software application or programming code. Blockchain minersmay also use a separate difficulty scheme and a separate proof-of-workscheme. The encryption/hashing algorithm, a difficulty algorithm, and aproof-of-work algorithm may thus be separately called or executed. Ablockchain may thus use any encryption algorithm, any difficultyalgorithm, and/or any proof-of-work algorithm. Blockchain environmentsmay thus mix-and-match different encryption, difficulty, and/orproof-of-work schemes when mining blockchain data. Each encryption,difficulty, and/or proof-of-work scheme may be separate, stand-aloneprograms, files, or third-party services. Blockchain miners may beagnostic to a particular blockchain's encryption, difficulty, and/orproof-of-work schemes, thus allowing any blockchain miner to process ormine data in multiple blockchains. GPUs, ASICs, and other specializedprocessing hardware components may be deterred by forcing cache misses,cache latencies, and processor stalls. Hashing, difficulty, and/orproof-of-work schemes require less programming code, consume lessstorage space/usage in bytes, and execute faster. Blockchain miningschemes may further randomize byte or memory block access, furtherimprove cryptographic security.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The features, aspects, and advantages of the exemplary embodiments areunderstood when the following Detailed Description is read withreference to the accompanying drawings, wherein:

FIGS. 1-19 are simplified illustrations of a blockchain environment,according to exemplary embodiments;

FIGS. 20-21 are more detailed illustrations of an operating environment,according to exemplary embodiments;

FIGS. 22-31 illustrate mining specifications, according to exemplaryembodiments;

FIG. 32 illustrates remote retrieval, according to exemplaryembodiments;

FIGS. 33-34 illustrate a bit shuffle operation, according to exemplaryembodiments;

FIGS. 35-36 illustrate a database table, according to exemplaryembodiments;

FIGS. 37-40 illustrate a table identifier mechanism, according toexemplary embodiments;

FIG. 41 illustrates agnostic blockchain mining, according to exemplaryembodiments

FIGS. 42-43 illustrate virtual blockchain mining, according to exemplaryembodiments;

FIG. 44 is a flowchart illustrating a method or algorithm for miningblockchain transactions, according to exemplary embodiments; and

FIG. 45 depicts still more operating environments for additional aspectsof exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments will now be described more fully hereinafterwith reference to the accompanying drawings. The exemplary embodimentsmay, however, be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein. Theseembodiments are provided so that this disclosure will be thorough andcomplete and will fully convey the exemplary embodiments to those ofordinary skill in the art. Moreover, all statements herein recitingembodiments, as well as specific examples thereof, are intended toencompass both structural and functional equivalents thereof.Additionally, it is intended that such equivalents include bothcurrently known equivalents as well as equivalents developed in thefuture (i.e., any elements developed that perform the same function,regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill inthe art that the diagrams, schematics, illustrations, and the likerepresent conceptual views or processes illustrating the exemplaryembodiments. The functions of the various elements shown in the figuresmay be provided through the use of dedicated hardware as well ashardware capable of executing associated software. Those of ordinaryskill in the art further understand that the exemplary hardware,software, processes, methods, and/or operating systems described hereinare for illustrative purposes and, thus, are not intended to be limitedto any particular named manufacturer.

As used herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless expressly stated otherwise. Itwill be further understood that the terms “includes,” “comprises,”“including,” and/or “comprising,” when used in this specification,specify the presence of stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof. It will be understood thatwhen an element is referred to as being “connected” or “coupled” toanother element, it can be directly connected or coupled to the otherelement or intervening elements may be present. Furthermore, “connected”or “coupled” as used herein may include wirelessly connected or coupled.As used herein, the term “and/or” includes any and all combinations ofone or more of the associated listed items.

It will also be understood that, although the terms first, second, etc.may be used herein to describe various elements, these elements shouldnot be limited by these terms. These terms are only used to distinguishone element from another. For example, a first device could be termed asecond device, and, similarly, a second device could be termed a firstdevice without departing from the teachings of the disclosure.

FIGS. 1-19 are simplified illustrations of a blockchain environment 20,according to exemplary embodiments. A miner system 22 receives one ormore inputs 24 via a communications network 26 from a blockchain networkserver 28. While the inputs 24 may be any electronic data 30, in theblockchain environment 20, the inputs 24 are blockchain transactions 32(such as financial transactions, inventory/shipping data, and/orhealthcare medical data). The actual form or content represented by theelectronic data 30 and the blockchain transactions 32 may beunimportant. The blockchain network server 28 sends, distributes, orbroadcasts the inputs 24 to some or all of the authorized miningparticipants (such as the miner system 22). The blockchain networkserver 28 may also specify a proof-of-work (“PoW”) target scheme 34,which may accompany the inputs 24 or be separately sent from the inputs24.

The miner system 22 may mine the inputs 24. When the miner system 22receives the inputs 24, the miner system 22 has a hardware processor(such as CPU 36) and a solid-state memory device 38 that collects theinputs 24 (such as the blockchain transactions 32) into a block 40 ofdata. The miner system 22 then finds a difficult proof-of-work (“PoW”)result 42 based on the block 40 of data. The miner system 22 performs,executes, or calls/requests a proof-of-work (“PoW”) mechanism 44. Theproof-of-work mechanism 44 is a computer program, instruction(s), orcode that instruct or cause the miner system 22 to call, request, and/orexecute an encryption algorithm 46. The proof-of-work mechanism 44 mayinstruct or cause the miner system 22 to call, request, and/or execute adifficulty algorithm 48 that generates or creates a difficulty 50. Theproof-of-work mechanism 44 may also instruct or cause the miner system22 to call, request, and/or execute a proof-of-work (“PoW”) algorithm52. The proof-of-work mechanism 44 may thus be one or more softwareapplications or programming schemes that separate the encryptionalgorithm 46 from the difficulty algorithm 48 and/or from theproof-of-work algorithm 52. Because the encryption algorithm 46 may beseparately executed/called from the difficulty algorithm 48 and/or fromthe proof-of-work algorithm 52, encryption of the electronic data 30(representing the inputs 24) is separately performed from the difficulty50 of solving the proof-of-work. In other words, any encryptionalgorithm 46 may be used, along with any difficulty algorithm 48, and/oralong with any proof-of-work algorithm 52.

FIG. 2 further illustrates the proof-of-work mechanism 44. While theencryption algorithm 46 may utilize any encryption scheme, process,and/or function, many readers may be familiar with a cryptographichashing algorithm 54 (such as the SHA-256 used by BITCOIN®). Thecryptographic hashing algorithm 54 may thus generate an output 56(sometimes called a digest 58) by implementing or executing thecryptographic hashing algorithm 54 using the inputs 24 (such as theblockchain transactions 32). So, whatever the arbitrary bit values ofthe inputs 24, and whatever the arbitrary bit length of the inputs 24,the cryptographic hashing algorithm 54 may generate the output 56 as oneor more hash values 60, perhaps having a fixed length (or n-bit). Theminer system 22 may thus receive the inputs 24 from the blockchainnetwork server 28, call and/or execute the encryption algorithm 46 (suchas the cryptographic hashing algorithm 54), and generate the hashvalue(s) 60.

As FIG. 3 illustrates, the miner system 22 may separately perform orcall the proof-of-work algorithm 52. After the encryption algorithm 46creates the output(s) 56, the miner system 22 may read/retrieve theoutput(s) 56 and send the output(s) 56 to the proof-of-work algorithm52. The miner system 22 may thus generate the proof-of-work result 42 bycalling and/or by executing the proof-of-work algorithm 52 using theoutput(s) 56. The miner system 22, for example, may send the hashvalue(s) 60 (generated by the cryptographic hashing algorithm 54) to theproof-of-work algorithm 52, and the proof-of-work algorithm 52 generatesthe proof-of-work result 42 using the hash value(s) 60. Theproof-of-work algorithm 52 may also compare the proof-of-work result 42to the proof-of-work (“PoW”) target scheme 34. The proof-of-workalgorithm 52 may, in general, have to satisfy or solve a mathematicalpuzzle 62, perhaps defined or specified by the proof-of-work targetscheme 34. The proof-of-work target scheme 34 may also specify, orrelate to, the difficulty 50 of solving the mathematical puzzle 62. Thatis, the more stringent or precise the proof-of-work target scheme 34(e.g., a minimum/maximum value of the hash value 60), the more difficultthe mathematical puzzle 62 is to solve. In other words, the difficulty50 is a measure of how difficult it is to mine the block 40 of data,given the solution requirements of the proof-of-work target scheme 34.

The miner system 22 may own the block 40 of data. If the miner system 22is the first to satisfy the proof-of-work target scheme 34 (e.g., theproof-of-work result 42 satisfies the mathematical puzzle 62), the minersystem 22 may timestamp the block 40 of data and broadcast the block 40of data, the timestamp, the proof-of-work result 42, and/or themathematical puzzle 62 to other miners in the blockchain environment 20.The miner system 22, for example, may broadcast a hash valuerepresenting the block 40 of data, and the other miners begin working ona next block in the blockchain 64.

Today's BITCOIN® difficulty is increasing. On or about Jun. 16, 2020,BITCOIN's network adjusted its difficulty level (the measure of how hardit is for miners to compete for block rewards on the blockchain) to15.78 trillion, which was nearly a 15% increase in the difficulty 50. Asthe difficulty 50 increases, older, less capable, and less powerefficient miners are unable to compete. As a result, today's BITCOIN®miners must have the latest, fastest hardware (such as an ASIC) toprofitably solve the mathematical puzzle 62 according to theproof-of-work target scheme 34. Indeed, Satoshi envisioned thatincreasing hardware speed would allow miners to easier solve theproof-of-work. Satoshi thus explained that the difficulty would be amoving target to slow down generation of the blocks 40 of data.

Conventional mining schemes are integrated. When a conventionalblockchain miner attempts to solve the mathematical puzzle 62, theconventional blockchain miner executes a conventional scheme thatintegrates hashing, difficulty, and proof-of-work. That is, conventionalproof-of-work schemes require the miners to execute a combined softwareoffering or pre-set combination of encryption and proof. Theseconventional proof-of-work scheme, in other words, integrate apredetermined encryption/hashing algorithm into or with a predetermineddifficulty and a predetermined proof-of-work algorithm. Theseconventional proof-of-work schemes thus force the miners to execute apredetermined or predefined scheme that functionally marries or bundlesencryption, difficulty, and proof-of-work.

The conventional schemes specify a difficulty mechanism. BITCOIN'sdifficulty mechanism, for example, is a measure of how difficult it isto mine a BITCOIN® block of data. BITCOIN® miners are required to find ahash value below a given target (e.g., SHA256(nonce+input) has n leadingzeros, where n determines the mining difficulty). The difficultyadjustment is directly related to the total estimated mining power(sometimes estimated in Total Hash Rate per second). BITCOIN'sdifficulty mechanism is adjusted to basically ensure that ten (10)minutes of computation are required before a miner may solve themathematical puzzle 62.

The conventional schemes force the use of specialized hardware. Whenblockchain mining first appeared, home/desktop computers and laptops(and their conventional processors or CPUs) were adequate. However, asblockchain mining became more difficult and competitive, miners gainedan advantage by repurposing a dedicated graphics processing unit (orGPU) for blockchain mining. As an example, the RADEON® HD 5970 GPU has aclocked processing speed of executing about 3,200 of 32-bit instructionsper clock, which is about 800 times more than the speed of a CPU thatexecutes only four (4) 32-bit instructions per clock. This increasedprocessor clock speed allowed GPUs to perform far more calculations andmade GPUs more desirable for cryptocurrency/blockchain mining. Later,field programmable gate arrays (FPGAs) were also re-modeled forcryptocurrency/blockchain mining. FPGAs were able to compute themathematical operations required to mine the block 40 of data twice asfast as the GPU. However, FPGA devices were more labor-intensive tobuild and still require customized configurations (both softwareprogramming and hardware). Today's BITCOIN® miners have pushed thehardware requirements even further by using a specializedapplication-specific integrated circuit (ASIC) that is exclusivelydesigned for blockchain mining. These ASICs may be 100 billion timesfaster than mere CPUs. These ASICs have made BITCOIN® miningundemocratic and only possible by a relatively few, well capitalizedentities running mining farms. Today's BITCOIN® miners thus consumegreat quantities of electrical power and pose concerns for theelectrical grid.

Today's conventional mining hardware has further specialized. Some ASICshave also been further designed for particular blockchains to achieveadditional optimizations. For example, a hardware implementation of theSHA-256 hash is much faster than a version coded in software. Today,nearly all BITCOIN® mining is performed using hardware ASICs.Specialized hardware has even been developed for particular hashingfunctions. The RAVENCOIN® scheme, as an example, uses several differenthashing algorithms, and a particular hashing algorithm is picked for oneblock based off of a hash of a previous block (the RAVENCOIN® schemeresembles a random selection of the hashing algorithm). However, becausefifteen (15) of the sixteen (16) algorithms sit on the sidelines unusedat any given time, the RAVENCOIN® scheme makes it very expensive for aminer to buy sixteen (16) different hardware rigs in order to mineaccording to the RAVENCOIN® scheme. Even if a miner decides to only minethe blocks that match a particular hardware requirement, the hardwarestill sits idle 14-15 cycles on average.

Some blockchains may also alter or modify the mining scheme. Forexample, the MONERO® mining scheme uses a specialized hashing functionthat implements a random change. That is, the MONERO® mining scheme usesa hash algorithm that unpredictably rewrites itself. The MONERO® miningnetwork introduced a RandomX mining algorithm that was designed to deterASICs and to improve the efficiency of conventional CPUs. MONERO'sRandomX mining algorithm uses random code execution and memory-intensivetechniques, rendering ASICs too expensive and ineffective to develop.

The conventional mining schemes thus have many disadvantages.Conventional mining schemes have become so specialized and so expensivethat only a small number of large miners have the resources to compete.Blockchain mining, in other words, has become centralized andundemocratic. Some conventional schemes try to find new hashingalgorithms, new proof-of-work schemes, or modify existing schemes tode-centralize and to democratize mining participants. Some conventionalmining schemes (such as ETHERTUIM®) require very large memory spaces inbytes, which disadvantages its hardware. LITECOIN® also disadvantageshardware by copying large byte amounts of data.

As FIGS. 4-6 illustrate, though, exemplary embodiments may mix-and-matchthe encryption algorithm 46, the difficulty algorithm 48, and theproof-of-work algorithm 52. The inventor has observed that there is nomining law or scheme that requires a preset or predefined difficultyscheme (such as BITCOIN'S counting zeroes on the hash to decide itsdifficulty). Instead, exemplary embodiments may use any encryptionalgorithm 46 that a cryptographic coin, network, or scheme desires orspecifies. Exemplary embodiments may use any difficulty algorithm 48that the cryptographic coin, network, or scheme desires or specifies.Exemplary embodiments may use any proof-of-work algorithm 52 that thecryptographic coin, network, or scheme desires or specifies. FIG. 4illustrates the encryption algorithm 46, the difficulty algorithm 48,and proof-of-work algorithm 52 as separate software mechanisms. FIG. 5illustrates alternative software mechanism where the difficultyalgorithm 48 and proof-of-work algorithm 52 may be functionallyintertwined, but the encryption algorithm 46 is a separate, stand-aloneprogram, file, or service. FIG. 6 illustrates the inputs and outputs forthe encryption algorithm 46, the difficulty algorithm 48, andproof-of-work algorithm 52.

FIG. 7 illustrates agnostic hashing. Exemplary embodiments may use anyencryption algorithm 46 that a cryptographic coin, blockchain network,or scheme desires or specifies. Because most blockchain mining schemesuse hashing, FIG. 7 illustrates the cryptographic hashing algorithm 54.The proof-of-work (“PoW”) target scheme 34 may thus use anycryptographic hashing algorithm 54, as exemplary embodiments areagnostic to hashing/encryption. The encryption algorithm 46 may be anycryptographic hashing algorithm 54 (e.g., the SHA-2 family (SHA-256 andSHA-512) and/or the SHA-3 family). The miner system 22 need onlyrequest, call, and/or execute the particular cryptographic hashingalgorithm 54 specified by the proof-of-work target scheme 34. FIG. 7thus illustrates an electronic database 70 of encryption algorithmsaccessible to the miner system 22. While the database 70 of encryptionalgorithms is illustrated as being locally stored in the memory device38 of the miner system 22, the database 70 of encryption algorithms maybe remotely stored and accessed/queried at any networked location. Eventhough the database 70 of encryption algorithms may have any logicalstructure, a relational database is perhaps easiest to understand. FIG.7 thus illustrates the database 70 of encryption algorithms as anelectronic table 72 that maps, converts, or translates differentproof-of-work target schemes 34 to their corresponding or associatedencryption algorithm 46 (such as the particular cryptographic hashingalgorithm 54). The miner system 22 may thus identify the encryptionalgorithm 46 by querying the electronic database 70 of encryptionalgorithms for the proof-of-work target scheme 34 specified for use bythe blockchain environment 20. So, once the particular cryptographichashing algorithm 54 is identified, the miner system 22 may acquire orretrieve any inputs 24 (such as the blockchain transactions 32) andexecute the cryptographic hashing algorithm 54 specified by theproof-of-work target scheme 34. The miner system 22 may optionally sendthe inputs 24 via the Internet or other network (e.g., thecommunications network 26 illustrated in FIGS. 1-3) to a remotedestination for service execution (as later paragraphs will explain).The encryption algorithm 46 (e.g., the cryptographic hashing algorithm54 specified by the proof-of-work target scheme 34) may thus generatethe output 56/digest 58 represented as the hash value(s) 60.

FIG. 8 illustrates agnostic difficulty. Exemplary embodiments may useany difficulty algorithm 48 that a cryptographic coin, blockchainnetwork, or scheme desires or specifies. For example, when or even afterthe encryption algorithm 46 (e.g., the cryptographic hashing algorithm54) generates the output 56 (such as the hash value(s) 60), the minersystem 22 may request, call, and/or execute the particular difficultyalgorithm 48 selected by, or specified by, the proof-of-work targetscheme 34 and/or the blockchain environment 20. The proof-of-work targetscheme 34 may thus use any difficulty algorithm 48, as the miner system22 is agnostic to difficulty. FIG. 8, for example, illustrates anelectronic database 74 of difficulty algorithms that is accessible tothe miner system 22. While the database 74 of difficulty algorithms isillustrated as being locally stored in the memory device 38 of the minersystem 22, the database 74 of difficulty algorithms may be remotelystored and accessed/queried at any networked location. Even though thedatabase 74 of difficulty algorithms may have any logical structure, arelational database is again perhaps easiest to understand. FIG. 8 thusillustrates the database 74 of difficulty algorithms as an electronictable 76 that maps, converts, or translates different proof-of-worktarget schemes 34 to their corresponding or associated difficultyalgorithm 48 (such as the particular cryptographic hashing algorithm54). The miner system 22 may thus identify the difficulty algorithm 48by querying the electronic database 74 of difficulty algorithms. So,once the particular difficulty algorithm 48 is identified, the minersystem 22 may acquire or retrieve any inputs that are required by thedifficulty algorithm 48 (such as the output hash value(s) 60 generatedby the cryptographic hashing algorithm 54). The miner system 22 mayexecute the difficulty algorithm 48 specified by the proof-of-worktarget scheme 34. The miner system 22 may optionally send the hashvalue(s) 60 via the Internet or other network (e.g., the communicationsnetwork 26 illustrated in FIGS. 1-3) to a remote destination for serviceexecution (as later paragraphs will explain). The difficulty algorithm48 creates or generates the difficulty 50 based on the hash value(s) 60.

FIG. 9 illustrates agnostic proof-of-work. Exemplary embodiments may useany proof-of-work algorithm 52 that a cryptographic coin, blockchainnetwork, or scheme desires or specifies. The proof-of-work target scheme34 may thus use any proof-of-work algorithm 52, as the miner system 22is agnostic to encryption, difficulty, and/or proof-of-work. FIG. 9, forexample, illustrates an electronic database 78 of proof-of-workalgorithms that is accessible to the miner system 22. While the database78 of proof-of-work algorithms is illustrated as being locally stored inthe memory device 38 of the miner system 22, the database 78 ofproof-of-work algorithms may be remotely stored and accessed/queried atany networked location. Even though the database 78 of proof-of-workalgorithms may have any logical structure, a relational database isagain perhaps easiest to understand. FIG. 9 thus illustrates thedatabase 78 of proof-of-work algorithms as an electronic table 80 thatmaps, converts, or translates different proof-of-work target schemes 34to their corresponding proof-of-work algorithm 52. The miner system 22may thus identify the proof-of-work algorithm 52 by querying theelectronic database 78 of proof-of-work algorithms. After the hashvalue(s) 60 are generated, and perhaps after the difficulty 50 isgenerated, the miner system 22 may execute the proof-of-work algorithm52 (specified by the proof-of-work target scheme 34) using the hashvalue(s) 60 and/or the difficulty 50 as inputs. The miner system 22 mayoptionally send the hash value(s) 60 and/or the difficulty 50 via theInternet or other network to a remote destination for service execution(as later paragraphs will explain). The proof-of-work algorithm 52generates the proof-of-work result 42 using the hash value(s) 60 and/orthe difficulty 50. The proof-of-work algorithm 52 may also compare theproof-of-work result 42 to the proof-of-work (“PoW”) target scheme 34 toensure or to prove a solution to the mathematical puzzle 62.

Exemplary embodiments may thus use any encryption algorithm 46, anydifficulty algorithm 48, and/or any proof-of-work algorithm 52.Exemplary embodiments may implement any cryptographic security. Insteadof merely counting zeroes (as specified by BITCOIN′), exemplaryembodiments may run the resulting hash value 60 through the difficultyalgorithm 48 to calculate the difficulty 50 in order to determinewhether it's more or less difficult than other hashes.

As FIG. 10 illustrates, exemplary embodiments may use any PoW targetscheme 34. There are many different target schemes, some of which use orspecify random number/nonce values, addresses, starting points, andother security schemes. The proof-of-work algorithm 52, for example, mayhave to compare the hash value(s) 60 to a target hash value 82. Thetarget hash value 82 may be any minimum or maximum hash value that mustbe satisfied. If the hash value 60 is less than or perhaps equal to thetarget hash value 82, then the proof-of-work algorithm 52 has perhapssolved the mathematical puzzle 62. However, if the hash value 60 isgreater than the target hash value 82, then perhaps the proof-of-workalgorithm 52 has failed to solve the mathematical puzzle 62. Likewise,the hash value 60 may need to be equal to or greater than the targethash value 82 to be satisfactory. Regardless, should the hash value 60fail to satisfy the target hash value 82, exemplary embodiments maymodify any data or input (e.g., the electronic data 30, a randomnumber/nonce value, address, starting points, etc.) according to theproof-of-work target scheme 34, again call or request the cryptographichashing algorithm 54 to generate the corresponding hash value(s) 60, andcompare the hash value(s) 60 to the target hash value 82. Exemplaryembodiments may repeatedly modify the electronic data 30 and/or anyother parameters until the corresponding hash value(s) 60 satisfy thetarget hash value 82.

Exemplary embodiments may also use any difficulty scheme. The inventorenvisions that there will be many different difficulty schemes. Thedifficulty algorithm 48, for example, may have to compare the difficulty50 to a target difficulty 84. The target difficulty 84 has a bit ornumeric value that represents a satisfactory difficulty of thecorresponding cryptographic hashing algorithm 54 and/or the hash value60. For example, suppose the target difficulty 84 is a minimum valuethat represents a minimum permissible difficulty associated with thecorresponding cryptographic hashing algorithm 54. If the difficulty 50is less than or perhaps equal to the target difficulty 84, then perhapsthe corresponding cryptographic hashing algorithm 54 and/or the hashvalue 60 is adequately difficult. However, if the difficulty 50 isgreater than the target difficulty 84, then perhaps the correspondingcryptographic hashing algorithm 54 and/or the hash value 60 is toodifficult. Likewise, the difficulty 50 may need to be equal to orgreater than the target difficulty 84 to be adequately difficult.Regardless, should the difficulty 50 fail to satisfy the targetdifficulty 84, exemplary embodiments may modify any data or input (e.g.,the electronic data 30, a random number/nonce value, address, startingpoints, etc.) and recompute the corresponding hash value(s) 60.Moreover, exemplary embodiments may additionally or alternatively changethe cryptographic hashing algorithm 54 and/or the difficulty algorithm48 and recompute.

Exemplary embodiments may thus functionally separate hashing,difficulty, and proof-of-work. The conventional proof-of-work targetscheme 34 functionally combines or performs both hashing and difficulty.The conventional proof-of-work target scheme 34 integrates or combinesthe difficulty in the hash. The conventional proof-of-work target scheme34 integrates or combines the difficulty in the hash, thus greatlycomplicating the hash determination. Exemplary embodiments, instead, mayseparate the hashing algorithm 54 from the difficulty algorithm 48.Exemplary embodiments put the difficulty 50 in the measurement of thedifficulty 50. Exemplary embodiments remove the difficulty 50 from thehashing algorithm 54. The hashing algorithm 54 is not complicated byalso having to integrate/calculate the difficulty algorithm 48. Thedifficulty algorithm 48 may thus be a separate, stand-alone function orservice that determines or calculates which hash is more difficult. Thehashing algorithm 54 is much simpler to code and much faster to execute,as the hashing algorithm 54 requires less programming code and lessstorage space/usage in bytes. The hashing algorithm 54 need not becomplicated to deter ASIC mining. Exemplary embodiments need not rely onthe hashing algorithm 54 to also determine the difficulty 50 and/or theproof-of-work. The difficulty algorithm 48 is, instead, a separatefunctional mechanism, perhaps performed or executed by a serviceprovider. Exemplary embodiments thus need not use an electricalpower-hungry mechanism that is inherent in the conventionalproof-of-work scheme.

FIG. 11 illustrates a randomized database table 90. The difficultyalgorithm 48 and/or the proof-of-work algorithm 52 may use or consultthe database table 90 when conducting any proof-of-work (e.g., 34 and/or44). While exemplary embodiments may use any encryption scheme, mostblockchain mining uses some form of hashing. FIG. 11 thus theproof-of-work target scheme 34 that utilizes the separate cryptographichashing algorithm 54, but the difficulty algorithm 48 and/or theproof-of-work algorithm 52 implements a further randomization of theresulting hash value(s) 60. The proof-of-work target scheme 34 ormechanism 44 may generate, store, and/or use the database table 90 whenperforming any proof-of-work. Exemplary embodiments may implement a bitshuffle operation 92 on the hash value(s) 60. Exemplary embodiments mayuse entries in the database table 90 to perform the bit shuffleoperation 92 (as later paragraphs will explain). Each entry 94 in thedatabase table 90 may contain a random selection of bits/bytes 96. Thedifficulty algorithm 48 and/or the proof-of-work algorithm 52 may selectany bit values representing the hash value(s) 60 and swap any one ormore of the bit values with any one or more entries 94 specified by thedatabase table 90. The difficulty algorithm 48 and/or the proof-of-workalgorithm 52 may read or select a bit portion of the bit valuesrepresenting the hash value(s) 60 and exchange or replace the bitportion with an entry 94 contained in, or referenced by, the databasetable 90. Each entry 94 in the database table 90 represents or isassociated with random bits or bytes. Exemplary embodiments may thusrandomly shuffle the hash value(s) 60 generated by the cryptographichashing algorithm 54. Exemplary embodiments randomize byte or memoryblock access.

FIG. 12 illustrates RAM binding. Exemplary embodiments may discourage ordeter the use of specialized hardware (such as GPUs and ASICs) inblockchain mining. The proof-of-work target scheme 34, for example, maytake advantage of, or target, memory size restrictions and cache latencyof any on-board processor cache memory 100. As the reader mayunderstand, any hardware processing element (whether a GPU, an ASIC, orthe CPU 36) may have integrated/embedded L1, L2, and L3 SRAM/DRAM cachememory. The processor cache memory 100 is generally much smaller than asystem/main memory (such as the memory device 38), so the hardwareprocessing element may store frequently-needed data and instructions.Because the processor cache memory 100 is physically much closer to theprocessing core, any hardware processing element is able to quicklyfetch or hit needed information. If the processor cache memory 100 doesnot store the needed information, then a cache miss has occurred and thehardware processing element must request and write blocks of data via amuch-slower bus from the system/main memory 38. A cache miss implies acache latency in time and/or cycles to fetch the needed information fromthe system/main memory 38. Any hardware processing element (again,whether a GPU, an ASIC, or the CPU 36) may sit idle, or stall, whileawaiting fetches from the system/main memory 38.

Exemplary embodiments may thus force latency, cache misses, and stalls.Exemplary embodiments may target cache latency and processor stalls bygenerating, storing, and/or using the database table 90 when determiningthe hash value(s) 60 (as later paragraphs will explain). The databasetable 90, however, may be sized to overload the processor cache memory100. The database table 90, in other words, may have a table byte size102 (in bits/bytes) that exceeds a storage capacity or cache byte size104 of the processor cache memory 100. The database table 90, forexample, may exceed one gigabyte (1 GB). Today's L1, L2, and L3processor cache memory is typically hundreds of megabits in size.Because the database table 90 may exceed one gigabyte (1 GB), anycaching operation will miss or invalidate. That is, the L1, L2, and L3processor cache memory 100 lacks the storage capacity or byte size 104to store the entire database table 90. Perhaps only a portion (orperhaps none) of the database table 90 may be stored in the processorcache memory 100. Indeed, exemplary embodiments thus force some, most,or even all of the database table 90 to be written or stored to themain/host memory device 38 (or accessed/retrieved from a remote source,as later paragraphs will explain). Because any hardware processingelement (again, whether a GPU, an ASIC, or the CPU 36) is unable tocache the entire database table 90, exemplary embodiments force a cachemiss and further force the hardware processing element to repeatedly usethe processor cache memory 100 to fetch and load a portion of thedatabase table 90. The main/system memory 38 thus provides perhaps aparticular portion of the database table 90 via the bus to the processorcache memory 100, and the processor cache memory 100 then provides thatparticular portion of the database table 90 to the hardware processingelement. The hardware processing element may then purge or delete thatparticular portion of the database table 90 from the processor cachememory 100 and request/fetch/load another portion of the database table90. Because exemplary embodiments may force repeated cache misses, thehardware processing element may continuously repeat this cycle forloading/retrieving most or all portions of the database table 90. Thehardware processing element, in other words, repeatedly queries theprocessor cache memory 100 and/or the main/host memory device 38 andawaits data retrieval. The hardware processing element must thereforesit, perhaps mostly idle, while the processor cache memory 100 and/orthe main/host memory device 38 processes, retrieves, and sends differentsegments/portions/blocks of the database table 90. The processor cachememory 100 and/or the main/host memory device 38 have the cache latency(perhaps measured in clock cycles, data transfer rate, or time) thatlimits blockchain computations. A faster processor/GPU/ASIC, in otherwords, will not improve memory access times/speeds, so any computationalspeed/performance is limited by the latency of repeatedly accessing theprocessor cache memory 100 and/or the main/host memory device 38. Thedatabase table 90 thus deters GPU/ASIC usage when processing theblockchain transactions 32. The database table 90 may thus bepurposefully designed to be non-cacheable by intensively using theprocessor cache memory 100 and/or the main/host memory device 38 as anASIC-deterrence mechanism.

Byte or memory block access may be randomized. Whatever the hashingalgorithm 54, exemplary embodiments may implement the bit shuffleoperation 92 on the hash value(s) 60. Exemplary embodiments may use theentries 94 in the database table 90 to perform the bit shuffle operation92 (as later paragraphs will further explain). The proof-of-work targetscheme 34 may use bit values representing the hash value(s) 60, but theproof-of-work target scheme 34 may swap any one or more of the bitvalues with any one or more entries 94 specified by the database table90. Each entry 94 in the database table 90 may contain a randomselection of bits/bytes. The proof-of-work target scheme 34 may causethe proof-of-work algorithm 52 to read or to select a bit portion of thebit values representing the hash value(s) 60 and exchange or replace thebit portion with an entry 94 contained in, or referenced by, thedatabase table 90. Each entry 94 in the database table 90 represents oris associated with random bits or bytes. The proof-of-work target scheme34 may thus randomly shuffle the hash value(s) 60 generated by thecryptographic hashing algorithm 54.

Exemplary embodiments may discourage or deter specialized hardware inblockchain mining. The miner system 22 must have access to the databasetable 90 in order to execute the bit shuffle operation 92, difficultyalgorithm 48, and/or the proof-of-work algorithm 52. Because anyprocessing component (e.g., ASIC, GPU, or the CPU 36) is unable to cachethe entire database table 90, exemplary embodiments force the processingcomponent to query the processor cache memory 100 and/or the main/hostmemory device 38 and to await data retrieval. The hardware processingcomponent must therefore sit, perhaps mostly idle, while the processorcache memory 100 and/or the main/host memory device 38 processes,retrieves, and sends different segments/portions/blocks of the databasetable 90. A faster GPU/ASIC will thus not improve memory accesstimes/speeds. Exemplary embodiments thus force miners to choose the CPU36, as a faster GPU/ASIC provides no performance/speed gain. Moreover,because a faster GPU/ASIC is ineffective, the extra capital expense of afaster GPU/ASIC offers little or no benefit and cannot be justified.Exemplary embodiments thus bind miners to the CPU 36 for blockchainprocessing/mining.

Exemplary embodiments thus include RAM hashing. The electronic databasetable 90 may have a random number of columns and/or a random number ofrows. The electronic database table 90 may have a random number ofdatabase entries 94. Moreover, each columnar/row database entry 94 mayalso have a random sequence or selection of bits/bytes (1's and 0's).So, whatever the hash values 60 generated by the hashing algorithm 54,the separate difficulty algorithm 48 and/or proof-of-work algorithm 52may use the electronic database table 90 to further randomize the hashvalues 60 for additional cryptographic security. Indeed, because only atleast a portion of the electronic database table 90 may be stored in theprocessor cache memory 100, exemplary embodiments effectively confinehashing operations to the main/host memory device 38 (such as asubsystem RAM). Regardless of what device or service provider executesthe hashing algorithm 54, the electronic database table 90, which ismostly or entirely stored in the main/host memory device 38, providesthe randomized inputs to the separate difficulty algorithm 48 and/orproof-of-work algorithm 52. Operationally and functionally, then,exemplary embodiments divorce or functionally separate any hardwareprocessing element from the hashing operation. Simply put, no matterwhat the performance/speed/capability of the ASIC, GPU, or the CPU 36,the database table 90 may be randomly sized to always exceed the storagecapacity or cache byte size 104 of the processor cache memory 100.Hashing operations are thus reliant on cache latency, cache misses, andprocessor stalls when using the database table 90. The hashingoperations are thus largely confined to, and performed by, the off-boardor off-processor main/host memory device 38 (such as a subsystem RAM).Because the main/host memory device 38 performs most or all of thecryptographic security, the hardware processing component (ASIC, GPU, orthe CPU 36) may play little or no role in the hashing operations(perhaps only performing database lookup queries). Again, abetter/faster ASIC or GPU provides little to no advantage in the hashingoperations. Moreover, the main/host memory device 38 consumes much lesselectrical power, thus further providing reduced energy costs thatdeter/resist ASIC/GPU usage.

Exemplary embodiments may also add cryptographic security. Exemplaryembodiments may force the miner/network to possess, or have authorizedaccess to, the database table 90. In simple words, the proof-of-worktarget scheme 34 swaps random bytes in the hash value 60 with otherrandom bytes specified by the database table 90. Any party that providesor determines a proof-of-work must possess (or have access to) thedatabase table 90. If the difficulty algorithm 48 and/or theproof-of-work algorithm 52 lacks authorized access to the database table90, then the difficulty algorithm 48 and/or the proof-of-work algorithm52 cannot query the database table 90 nor perform database lookupoperations. Difficulty and/or proof-of-work will fail without havingaccess to the database table 90.

Exemplary embodiments may also separately specify the difficultyalgorithm 48. The proof-of-work target scheme 34 may cause the minersystem 22 to apply the bit shuffle operation 92 to the hash value 60.The proof-of-work target scheme 34 may also specify the difficultyalgorithm 48 and the target difficulty 84, perhaps having a high numberor value. Because these byte accesses to the processor cache memory 100are random and over a gigabyte of the memory space, the byte accessesblow or exceed the retrieval and/or byte size storage capabilities ofthe processor cache memory 100. The proof-of-work target scheme 34 thusforces the miner system 22 to wait on the slower main/host memory device38 (rather than waiting on the speed of the hardware processingcomponent). A faster/better hardware processing element (such as anASIC), in other words, does not alleviate the bottleneck of accessingthe main/host memory device 38. Moreover, because exemplary embodimentsmay heavily rely on the main/host memory device 38 (rather than thehardware processing component) to do proof of work, the miner system 22consumes significantly less of electrical power (supplied by a powersupply 110). Because the proof-of-work algorithm 52 and the difficultyalgorithm 48 may be separate from the cryptographic hashing algorithm54, exemplary embodiments utilize the security of a well-tested hashingfunction, but exemplary embodiments also require the proof-of-workscheme to use the main/host memory device 38, which makes itunreasonable to build ASICS.

Exemplary embodiments may thus force usage of a particular physicalmemory. Exemplary embodiments, for example, may overload the processorcache memory 100 by gorging the byte size of the database table 90 withadditional database entries. Even as L1, L2, and L3 processor cachememory 100 increases in the storage capacity or byte size 104, exemplaryembodiments may concomitantly increase the table byte size 102 (inbits/bytes) to ensure the database table 90 continues to exceeds thestorage capacity or byte size 104 of the processor cache memory 100.Exemplary embodiments may thus bind the encryption algorithm 46, thedifficulty algorithm 48, and/or the proof-of-work algorithm 52 to themain/host memory device 38 to deter GPU/ASIC usage.

Exemplary embodiments may also unbind the hashing algorithm 54 from thedifficulty algorithm 48. Exemplary embodiments easily validate theproof-of-work by changing how proof-of-work is calculated withoutchanging the hashing algorithm 54. Because the hashing algorithm 54 isdisassociated or disconnected from the difficulty algorithm 48, thecryptographically security of the hashing algorithm 54 is increased orimproved. Moreover, the separate difficulty algorithm 48 and/orproof-of-work algorithm 52 may have other/different objectives, withoutcompromising the cryptographically security of the hashing algorithm 54.The difficulty algorithm 48 and/or proof-of-work algorithm 52, forexample, may be designed for less consumption of the electrical power.The difficulty algorithm 48 and/or proof-of-work algorithm 52 mayadditionally or alternatively be designed to deter/resist ASIC/GPUusage, such as increased usage of the processor cache memory 100 and/orthe main/host memory device 38. The difficulty algorithm 48 and/orproof-of-work algorithm 52 need not be cryptographically secure. Becausethe hashing algorithm 54 ensures the cryptographically security, thedifficulty algorithm 48 and/or proof-of-work algorithm 52 need not beburdened with providing the cryptographically security. The difficultyalgorithm 48 and/or proof-of-work algorithm 52 each require lessprogramming code and less storage space/usage in bytes, so each is muchsimpler to code and much faster to execute.

FIG. 13 illustrates network binding. Because the encryption algorithm46, the difficulty algorithm 48, and the proof-of-work algorithm 52 maybe separate software modules, routines, or clients, networkcommunications may be used to deter specialized hardware. As FIG. 13illustrates, the miner system 22 communicates with the blockchainnetwork server 28 via the communications network 26. Because the minersystem 22 may be authorized to perform blockchain mining (perhapsaccording to the proof-of-work target scheme 34 specified or used by theblockchain network server 28), the miner system 22 may receive theinputs 24 from the blockchain network server 28. The miner system 22, inother words, must use the communications network 26 to receive theinputs 24 and to subsequently mine the inputs 24. The miner system 22uses the inputs 24 to determine the hash value 60 and/or the difficulty50 (as this disclosure above explains). However, suppose the blockchainnetwork server 28 stores the database table 90 that is required for thedifficulty algorithm 48 and/or the proof-of-work algorithm 52. Eventhough the miner system 22 may execute the encryption algorithm 46, thedifficulty algorithm 48, and/or the proof-of-work algorithm 52, theminer system 22 may be forced to send one or more database queries tothe blockchain network server 28. The blockchain network server 28 mayhave a hardware processing element and a memory device (not shown forsimplicity) that stores the database table 90. The blockchain networkserver 28 may also store and execute a query handler softwareapplication (also not shown for simplicity) that receives queries fromclients, identifies or looks up entries 94 in the database table 90, andsends query responses to the clients. So, when the miner system 22 isinstructed to perform, or require, the bit shuffle operation 92, theminer system 22 may thus be forced to retrieve any entry 94 (specifiedby the database table 90) via the communications network 26 from theblockchain network server 28. The miner system 22 may thus send thedatabase query to the network address assigned to or associated with theblockchain network server 28. The miner system 22 then awaits a queryresponse sent via the communications network 26 from the blockchainnetwork server 28, and the query response includes or specifies therandom selection of bits/bytes retrieved from the particular entry 94 inthe database table 90. The miner system 22 may then perform the bit swapoperation 92 on the hash value(s) 60 (as this disclosure aboveexplains).

Exemplary embodiments may use a network latency 112 to discourage ordeter specialized hardware. Because the blockchain network server 28 maystore the database table 90, the miner system 22 is performance bound bythe network latency 112 in the communications network 26. Packetcommunications between the blockchain network server 28 and thedestination miner system 22 require time, and the network latency 112 isaffected by network routing, network segment travel distances, networktraffic, and many other factors. Exemplary embodiments may thusadditionally or alternatively force the miner system 22 to wait on thecommunications network 26 to obtain any entry 94 in the database table90. A faster/better hardware processing component (such as an ASIC) doesnot overcome bottleneck(s) due to the network latency 112 in thecommunications network 26. Moreover, because the electrical powerrequired by a network interface 114 is likely less than the hardwareprocessing component, the miner system 22 consumes significantly less ofelectrical power.

FIG. 14 illustrates party binding. Here the miner system 22 may utilizean authorized proof-of-work (“PoW”) service provider 120 that provides aPoW service 122. The miner system 22 may communicate with a PoW server124 via the communications network 26, and the PoW server 124 isoperated by, or on behalf of, the PoW service provider 120. Perhaps onlythe PoW service provider 120 may be authorized to execute the difficultyalgorithm 48 and/or the proof-of-work algorithm 52 as a provable party.The PoW server 124 may have a hardware processing element and a memorydevice (not shown for simplicity) that stores the difficulty algorithm48 and/or the proof-of-work algorithm 52. If an incorrect orunauthorized party attempts the proof-of-work, the proof-of-work isdesigned to fail. As an example, FIG. 14 illustrates a party identifier126 as one of the inputs 24 to the difficulty algorithm 48 and to theproof-of-work algorithm 52. While the party identifier 126 may besupplied or sent from any network location (such as the blockchainnetwork server 28 and/or the miner system 22), the party identifier 126may be locally retrieved from the memory device of the PoW server 124.The miner system 22 may send a PoW request 128 to a network address(e.g., IP address) associated with the PoW server 124. The PoW request128 may include or specify one or more of the inputs 24 to thedifficulty algorithm 48 and/or to the proof-of-work algorithm 52.Suppose, for example, that the PoW request 128 includes or specifies thehash value(s) 60 (determined by the hashing algorithm 54, as aboveexplained). The PoW server 124 may generate the difficulty 50 (bycalling or executing the difficulty algorithm 48) and/or theproof-of-work result 42 (by calling and/or by executing theproof-of-work algorithm 52) using the hash value(s) 60 and the partyidentifier 126. The PoW server 124 may then send the difficulty 50and/or the proof-of-work result 42 as a PoW service response 130 back tothe IP address associated with the miner system 22 and/or back to the IPaddress associated with the blockchain network server 28. Either or bothof the PoW server 124 and/or the blockchain network server 28 maycompare the difficulty 50 and/or the proof-of-work result 42 to theproof-of-work (“PoW”) target scheme 34. If the difficulty 50 and/or theproof-of-work result 42 satisfies the proof-of-work (“PoW”) targetscheme 34, then the correct, authorized party has solved themathematical puzzle 62 associated with the mining scheme.

Exemplary embodiments may thus be socially bound. Because the partyidentifier 126 may be an input to the difficulty algorithm 48 and/or tothe proof-of-work algorithm 52, the party identifier 126 must specifythe correct name, code, alphanumeric combination, binary value, or anyother representation of the PoW service provider 120. If the wrong,incorrect, or unauthorized value is input, the difficulty algorithm 48and/or the proof-of-work algorithm 52 will generate incorrect resultsthat cannot satisfy the proof-of-work (“PoW”) target scheme 34. Anunauthorized party has been used to conduct the proof-of-work.

FIG. 15 illustrates machine binding. Here the miner system 22 mayutilize a particular machine, device, or other computer to provide thePoW service 122. The miner system 22, for example, must use the PoWserver 124 to execute the difficulty algorithm 48 and/or theproof-of-work algorithm 52 as a provable party. That is, perhaps onlythe PoW server 124 is authorized to execute the difficulty algorithm 48and/or the proof-of-work algorithm 52. A different computer or server,even if also operated by, or on behalf of, the PoW service provider 120,is ineligible or unauthorized. FIG. 15 thus illustrates a machineidentifier 130 as one of the inputs 24 to the difficulty algorithm 48and/or to the proof-of-work algorithm 52. The machine identifier 130 isany value, number, or alphanumeric combination that uniquely identifiesthe PoW server 124 executing the difficulty algorithm 48 and/or theproof-of-work algorithm 52. The machine identifier 130, for example, maybe a chassis or manufacturer's serial number, MAC address, or IP addressthat is assigned to or associated with the PoW server 124. When the PoWserver 124 receives the input(s) 24 from the miner system 22 (perhapsvia the PoW request 128, as above explained), the PoW server 124 maygenerate the difficulty 50 and/or the proof-of-work result 42 using thehash value(s) 60 and the machine identifier 130 as inputs. The PoWserver 124 may then send the difficulty 50 and/or the proof-of-workresult 42 as a PoW service response 130 back to the IP addressassociated with the miner system 22 and/or back to the IP addressassociated with the blockchain network server 28. Either or both of thePoW server 124 and/or the blockchain network server 28 may compare thedifficulty 50 and/or the proof-of-work result 42 to the proof-of-work(“PoW”) target scheme 34. If the difficulty 50 and/or the proof-of-workresult 42 satisfy the proof-of-work (“PoW”) target scheme 34, then thecorrect, authorized machine or device has solved the mathematical puzzle62 associated with the mining scheme. Exemplary embodiments may thus bemachine bound. If the wrong, incorrect, or unauthorized machineidentifier 130 is input, the difficulty algorithm 48 and/or theproof-of-work algorithm 52 will generate incorrect results that cannotsatisfy the proof-of-work (“PoW”) target scheme 34. An unauthorizedcomputer has been used to conduct the proof-of-work.

FIG. 16 further illustrates network binding. Here a predeterminednetwork addressing scheme must be used to conduct the difficulty 50and/or the proof-of-work result 42. Suppose, for example, that theproof-of-work (“PoW”) target scheme 34 requires one or morepredetermined network addresses 134 when executing the difficultyalgorithm 48 and/or the proof-of-work algorithm 52. The inputs 24 to thedifficulty algorithm 48 and/or to the proof-of-work algorithm 52, forexample, may include one or more source addresses 136 and/or one or moredestination addresses 138 when routing packetized data via thecommunications network 26 from the miner system 22 to the PoW serviceprovider 120 (e.g., the PoW server 124). The hash values 60, in otherwords, must traverse or travel a predetermined network routing 140 inorder to satisfy the proof-of-work (“PoW”) target scheme 34. Thepredetermined network routing 140 may even specify a chronological listor order of networked gateways, routers, switches, servers, and othernodal addresses that pass or route the inputs 24 from the miner system22 to the PoW server 124. The source addresses 136, the destinationaddresses 138, and/or the predetermined network routing 140 may thus beadditional data inputs 24 to the difficulty algorithm 48 and/or to theproof-of-work algorithm 52. The PoW server 124 may perform networkpacket inspection to read/retrieve the source addresses 136, thedestination addresses 138, and/or the predetermined network routing 140associated with, or specified by, a data packet. When the PoW server 124receives the input(s) 24 from the miner system 22 (perhaps via the PoWrequest 128, as above explained), the PoW server 124 may generate thedifficulty 50 and/or the proof-of-work result 42 using the hash value(s)60, the source addresses 136, the destination addresses 138, and/or thepredetermined network routing 140. The PoW server 124 may then send thedifficulty 50 and/or the proof-of-work result 42 as the PoW serviceresponse 130 back to the IP address associated with the miner system 22and/or back to the IP address associated with the blockchain networkserver 28. Either or both of the PoW server 124 and/or the blockchainnetwork server 28 may compare the difficulty 50 and/or the proof-of-workresult 42 to the proof-of-work (“PoW”) target scheme 34. If thedifficulty 50 and/or the proof-of-work result 42 satisfy theproof-of-work (“PoW”) target scheme 34, then the correct, authorizednetworked devices were used to solve the mathematical puzzle 62associated with the mining scheme. If a wrong, incorrect, orunauthorized routing was used, the difficulty algorithm 48 and/or theproof-of-work algorithm 52 will fail to satisfy the proof-of-work(“PoW”) target scheme 34. An unauthorized network of computers has beenused to conduct the proof-of-work.

FIG. 17 illustrates vendor processing. The miner system 22 maycommunicate with one or more service providers via the communicationsnetwork 26. The miner system 22 may enlist or request that any of theservice providers provide or perform a processing service. An encryptionservice provider 150, for example, may provide an encryption service 152by instructing an encryption server 154 to execute the encryptionalgorithm 46 chosen or specified by the miner system 22 and/or theblockchain network server 28. A difficulty service provider 156 mayprovide a difficulty service 158 by instructing a difficulty server 160to execute the difficulty algorithm 48 chosen or specified by the minersystem 22 and/or the blockchain network server 28. The proof-of-work(PoW) service provider 120 (e.g., the PoW server 124) may provide thePoW service 122 by executing the proof-of-work algorithm 52 chosen orspecified by the miner system 22 and/or the blockchain network server28. The miner system 22 may thus outsource or subcontract any of theencryption algorithm 46, the difficulty algorithm 48, and/or theproof-of-work algorithm 52 to the service provider(s). Because theencryption algorithm 46, the difficulty algorithm 48, and/or theproof-of-work algorithm 52 may be separate software mechanisms orpackages, the service providers 150, 156, and 120 may specialize intheir respective algorithms 46, 48, and 52 and/or services 152, 158, and122. The encryption service provider 150, for example, may offer aselection of different encryption services 152 and/or encryptionalgorithms 46, with each encryption service 152 and/or encryptionalgorithm 46 tailored to a specific encryption need or feature. Thedifficulty service provider 156 may offer a selection of differentdifficulty services 158 and/or difficulty algorithms 48 that aretailored to a specific difficulty need or feature. The PoW serviceprovider 120 may offer a selection of different PoW services 122 and/orPoW algorithms 52 that are tailored to a specific proof-of-work need orfeature. The blockchain network server 28, the miner system 22, and/orthe proof-of-work (“PoW”) target scheme 34 may thus mix-and-matchencryption, difficulty, and proof-of-work options.

Exemplary embodiments may thus decouple encryption, difficulty, andproof-of-work efforts. Because the encryption algorithm 46 may be astand-alone software offering or module, exemplary embodiments greatlyimprove encryption security. The encryption algorithm 46 (such as thehashing algorithm 54) need not intertwine with the difficulty algorithm48 and/or the proof-of-work algorithm 52. Because the hashing algorithm54 may be functionally divorced from difficulty and proof-of-workcalculations, the hashing algorithm 54 remains a safe, secure, andproven cryptology scheme without exposure to software bugs and errorsintroduced by difficulty and proof-of-work needs. The difficultyalgorithm 48 may also be severed or isolated from encryption andproof-of-work, thus allowing a blockchain scheme to dynamically alter orvary different difficulty calculations without affecting encryptionand/or proof-of-work. The proof-of-work algorithm 52 may also bepartitioned, split off, or disconnected from encryption and difficulty,thus allowing any blockchain scheme to dynamically alter or varydifferent proof-of-work calculations or schemes without affectingencryption and/or difficulty.

FIG. 18 illustrates democratic mining. Exemplary embodiments reduce oreven eliminate the need for graphics processors and specializedapplication-specific integrated circuits. The miner system 22 may thusrely on a conventional central processing unit (such as the CPU 36) toprocess the blockchain transactions 32. The miner system 22 may thus bea conventional home or business server/desktop 160 or laptop computer162 that is much cheaper to purchase, use, and maintain. Moreover, theminer system 22 may even be a smartphone 164, tablet computer 166, orsmartwatch 168, as these devices also have adequate processing andmemory capabilities to realistically mine and win the block 40 of data(illustrated in FIGS. 1-10). Indeed, the miner system 22 may be anynetwork-connected device, as exemplary embodiments reduce or eveneliminate the need for specialized hardware processors. The miner system22 thus opens-up blockchain mining to any network-connected appliance(e.g., refrigerator, washer, dryer), smart television, camera, smartthermostat, or other Internet of Thing.

FIG. 19 also illustrates democratic mining. Because exemplaryembodiments reduce or even eliminate the need for graphics processorsand specialized application-specific integrated circuits, the minersystem 22 may even be a car, truck, or other vehicle 170. As the readermay realize, the vehicle 170 may have many electronic systemscontrolling many components and systems. For example, the engine mayhave an engine electronic control unit or “ECU” 172, the transmissionmay have a powertrain electronic control unit or “PCU” 174, the brakingsystem may have a brake electronic control unit or “BCU” 176, and thechassis system may have a chassis electronic control unit or “CUC” 178.There may be many more electronic control units throughout the vehicle170. A controller area network 180 thus allows all the variouselectronic control units to communicate with each other (via messagessent/received via a CAN bus). All these controllers may also interfacewith the communications network 26 via a wireless vehicle transceiver182 (illustrated as “TX/RX”). The vehicle 170 may thus communicate withthe blockchain network server 28 to receive the inputs 24 (such as theblockchain transactions 32). The vehicle 170 may then use the variouscontrollers 172-178 to mine the blockchain transactions 32 using theencryption algorithm 46, the difficulty algorithm 48, and/or the PoWalgorithm 52 (as this disclosure above explains). The reader mayimmediately see that the vehicle 170 is a powerful processing platformfor blockchain mining. The vehicle 170 may mine the blockchaintransactions 32 when moving or stationary, as long as electrical poweris available to the various controllers 172-178 and to the vehicletransceiver 182. Indeed, even when parked with theignition/battery/systems on or off, exemplary embodiments may maintainthe electrical power to mine the blockchain transactions 32. So, adriver/user may configure the vehicle 17 to mine the blockchaintransactions 32, even when the vehicle sits during work hours, sleephours, shopping hours, and other times of idle use. The reader may alsoimmediately see that vehicular mining opens up countless additionalpossibilities to win the block 40 of data (i.e., solve the puzzle 62)without additional investment in mining rigs. Thousands, millions, oreven billions of vehicles 170 (e.g., cars, trucks, boats, planes, buses,trains, motorcycles) may mine the blockchain transactions 32, thusproviding a potential windfall to offset the purchasing and operationalexpenses.

Exemplary embodiments reduce energy consumption. Because a conventional,general purpose central processing unit (e.g., the CPU 36) is adequatefor mining the blockchain transactions 32, exemplary embodiments consumemuch less electrical power. Moreover, because a conventional centralprocessing unit consumes much less electrical power, the CPU operates atmuch cooler temperatures, generates less waste heat/energy, andtherefore requires less cooling, air conditioning, and refrigerantmachinery. Exemplary embodiments are thus much cheaper to operate thanGPUs and ASICs.

Exemplary embodiments thus democratize blockchain mining. Becauseencryption, difficulty, and proof-of-work efforts may be functionallydivided, general-purpose computer equipment has the processing andmemory capability to compete as blockchain miners. For example, becausethe function(s) that calculate(s) the magnitude of the proof of work(such as the difficulty algorithm 48 and/or the proof-of-work algorithm52) may be detached or isolated from the function that performscryptography (such as the hashing algorithm 54), encryption need not bemodified in order to improve security (e.g., such as the MONERO® miningscheme). The well-tested SHA-256 hashing function, for example, remainsstable and unaffected by difficulty and/or proof-of-work. The difficultyalgorithm 48, in other words, need not be determined by or with thehashing algorithm 54. The difficulty algorithm 48, instead, may beseparately determined as a true, independent measure of the difficulty50. The inventor has realized that most or all proof of work schemesgenerally may have two functions (i.e., one function to do acryptographic hash and another function to determine the level ofdifficulty of a given hash). Exemplary embodiments may separate, or takeaway, what makes proof of work hard from the cryptographic hash and,perhaps instead, put it in the difficulty algorithm 48 that calculateswhich hash is more difficult. The difficulty algorithm 48, for example,may be functionally combined with the proof-of-work algorithm 52 thatcalculates the magnitude of the proof of work instead of using thehashing algorithm 54 (as FIG. 5 illustrates). Exemplary embodiments neednot try to design, develop, or modify hashing functions that deter ASICmining.

Encryption may thus be independent from proof-of-work determinations.The proof of work (such as the difficulty algorithm 48 and/or theproof-of-work algorithm 52) may be a different or separate softwaremechanism from the hashing mechanism. The difficulty 50 of theproof-of-work, for example, may be a separate component from staking ina blockchain. The difficulty algorithm 48 and/or the proof-of-workalgorithm 52 may require communications networking between provablydifferent parties. The difficulty algorithm 48 and/or the proof-of-workalgorithm 52 may require network delays and/or memory bandwidthlimitations. The difficulty algorithm 48 and/or the proof-of-workalgorithm 52 may have a random component (such as incorporating a randomfunction), such that the difficulty algorithm 48 and/or theproof-of-work algorithm 52 may randomly to determine the difficulty 50and/or the proof-of-work result 42. Exemplary embodiments thus reduce oreven eliminate the power intensive mechanism that is inherent in today'sproof of work schemes by changing how the proof of work is calculated.Exemplary embodiments need not change the hashing algorithm 54, andexemplary embodiments allow a more easily validated proof of work. Thehashing algorithm 54 is not bound or required to determine the proof ofwork. The proof of work need not be cryptographically secure. Theliberated, autonomous hashing algorithm 54 generates and guarantees aninput (e.g., the hash values 60) that cannot be predicted by some otherfaster algorithm. The disassociated hashing algorithm 54 effectivelygenerates the hash values 60 as random numbers. The hashing algorithm54, in other words, provides cryptographic security, so neither thedifficulty algorithm 48 nor the proof-of-work algorithm 52 need becryptographically secure. The difficulty algorithm 48 and/or theproof-of-work algorithm 52 need not be folded into the hashing algorithm54.

Exemplary embodiments provide great value to blockchains. Exemplaryembodiments may functionally separate encryption (e.g., the hashingalgorithm 54) from proof of work (such as the difficulty algorithm 48and/or the proof-of-work algorithm 52). Exemplary embodiments may thusbind proof-of-work to a conventional central processing unit. Deployinga different cryptographic hash is hugely dangerous for blockchains, butdeploying another difficulty or proof of work mechanism is not sodangerous. Exemplary embodiments allow blockchains to experiment withdifferent difficulty functions (the difficulty algorithms 48) and/ordifferent proof-of-work algorithms 52 without changing the hashingalgorithm 54. Exemplary embodiments thus mitigate risk and reduceproblems with cryptographic security. Many blockchain environments wouldprefer to make their technology CPU mineable for lower power, lowercosts, and more democratic participation. The barrier, though, is thatconventionally these goals would require changing their hash function.Exemplary embodiments, instead, reduce costs and increase the pool ofminer systems without changing the hash function. The difficultyalgorithm 48 and/or the proof-of-work algorithm 52 may be refined,modified, or even replaced with little or no impact on the hashingalgorithm 54.

Exemplary embodiments reduce electrical power consumption. Blockchainmining is very competitive, as the first miner that solves themathematical puzzle 62 owns the block 40 of data and is financiallyrewarded. Large “farms” have thus overtaken blockchain mining, with eachminer installation using hundreds or even thousands of ASIC-basedcomputers to improve their chances of first solving the calculationsspecified by the mathematical puzzle 62. ASIC-based blockchain miningrequires tremendous energy resources, though, with some studiesestimating that each BITCOIN® transaction consumes more dailyelectricity than an average American home. Moreover, because ASIC-basedblockchain mining operates 24/7/365 at full processing power, theASIC-based machines quickly wear out or fail and need periodic (perhapsyearly) replacement. Exemplary embodiments, instead, retarget blockchainmining back to CPU-based machines that consume far less electrical powerand that cost far less money to purchase. Because the capital costs andexpenses are greatly reduced, more miners and more CPU-based machinesmay effectively participate and compete. The CPU-based machines, inother words, have a realistic and profitable chance of first solving thecalculations specified by the mathematical puzzle 62. Democraticparticipation is greatly increased.

FIGS. 20-21 are more detailed illustrations of an operating environment,according to exemplary embodiments. FIG. 20 illustrates the blockchainnetwork server 28 communicating with the miner system 22 via thecommunications network 26. The blockchain network server 28 and theminer system 22 operate in the blockchain environment 20. The blockchainnetwork server 28 has a hardware processing component 190 (e.g., “P”)that executes a server-side blockchain software application 192 storedin a local memory device 194. The blockchain network server 28 has anetwork interface to the communications network 26, thus allowingtwo-way, bidirectional communication with the miner system 22. Theserver-side blockchain software application 192 includes instructions,code, and/or programs that cause the blockchain network server 28 toperform operations, such as sending the inputs 24 (such as theblockchain transactions 32) and/or the proof-of-work (“PoW”) targetscheme 34 via the communications network 26 to the network address(e.g., Internet protocol address) associated with or assigned to theminer system 22. The inputs 24 may be any electronic data 30 that isshared among miners participating in the blockchain environment 20.

The miner system 22 operates as a mining node in the blockchainenvironment 20. The miner system 22 has the central processing unit(e.g., “CPU”) 36 that executes a client-side blockchain mining softwareapplication 196 stored in the local memory device 38. The miner system22 has a network interface to the communications network 26, thusallowing two-way, bidirectional communication with the blockchainnetwork server 28. The client-side blockchain mining softwareapplication 196 includes instructions, code, and/or programs that causethe miner system 22 to perform operations, such as receiving the inputs24, the electronic data 30, and/or the proof-of-work (“PoW”) targetscheme 34. The client-side blockchain mining software application 196may then cause the miner system 22 to execute the proof-of-work (“PoW”)mechanism 44 based on the electronic data 30 representing the inputs 24.The client-side blockchain mining software application 196 may instructthe CPU 36 to call and/or to execute the encryption algorithm 46, thedifficulty algorithm 48, and/or the PoW algorithm 52. The CPU 36 callsor executes any or all of the encryption algorithm 46, the difficultyalgorithm 48, and/or the PoW algorithm 52 using the electronic data 30.

The miner system 22 mines blockchain transactional records. Whatever theelectronic data 30 represents, the miner system 22 applies theelectronic data 30 according to the proof-of-work target scheme 34.While the proof-of-work target scheme 34 may specify any encryptionalgorithm 46, most blockchains specify the hashing algorithm 54. Theminer system 22 may thus generate the hash values 60 by hashing theelectronic data 30 (e.g., the blockchain transactions 32) using thehashing algorithm 54. The miner system 22 may generate the difficulty 50by executing the difficulty algorithm 48 using the hash values 60. Theminer system 22 may generate the proof-of-work result 42 using the hashvalue(s) 60 as inputs to the proof-of-work algorithm 52. If theproof-of-work result 42 satisfies the mathematical puzzle 62, accordingto the rules/regulations specified by the blockchain network server 28and/or the proof-of-work target scheme 34, then perhaps the miner system22 earns or owns the right or ability to write/record blockchaintransaction(s) to the block 40 of data. The miner system 22 may alsoearn or be rewarded with a compensation (such as a cryptographic coin,points, other currency/coin/money, or other value).

The miner system 22 may own the block 40 of data. If the miner system 22is the first to satisfy the proof-of-work target scheme 34 (e.g., theproof-of-work result 42 satisfies the mathematical puzzle 62), the minersystem 22 earns the sole right or ability to write the blockchaintransactions 32 to the block 40 of data. The miner system 22 maytimestamp the block 40 of data and broadcast the block 40 of data, thetimestamp, the proof-of-work result 42, and/or the mathematical puzzle62 to other miners in the blockchain environment 20. The miner system22, may broadcast a hash value representing the block 40 of data. Theminer system 22 thus adds or chains the block 40 of data (and perhapsits hash value) to the blockchain 64, and the other miners begin workingon a next block in the blockchain 64.

The proof-of-work target scheme 34 and/or the mathematical puzzle 62 mayvary. Satoshi's BITCOIN® proof-of-work scanned for a value that, whenhashed, the hash value begins with a number of zero bits. The averagework required is exponential in the number of zero bits required and canbe verified by executing a single hash. BITCOIN's miners may increment anonce in the block 40 of data until a value is found that gives theblock's hash the required zero bits.

FIG. 21 further illustrates the operating environment. The miner system22 may optionally utilize vendors for any of the hashing algorithm 54,the difficulty algorithm 48, and the proof-of-work algorithm 52. Theminer system 22 may enlist or request that a service provider provide orperform a processing service. The encryption server 154, for example,may communicate with the blockchain network server 28 and the minersystem 22 via the communications network 26. The encryption server 154has a hardware processing element (“P”) that executes the encryptionalgorithm 46 stored in a local memory device. The encryption server 154is operated on behalf of the encryption service provider 150 andprovides the encryption service 152. The miner system 22 and/or theblockchain network server 28 may send an encryption service request tothe encryption server 154, and the encryption service request mayspecify the inputs 24 (such as the blockchain transactions 32). Theencryption server 154 executes the encryption algorithm 46 using theinputs 24 to generate the hash value(s) 60. The encryption server 154sends a service response to the miner system 22, and the serviceresponse includes or specifies the hash value(s) 60.

Other suppliers may be used. The difficulty server 160 may communicatewith the blockchain network server 28 and the miner system 22 via thecommunications network 26. The difficulty server 160 has a hardwareprocessing element (“P”) that executes the difficulty algorithm 48stored in a local memory device. The difficulty service provider 156 mayprovide the difficulty service 158 by instructing the difficulty server160 to execute the difficulty algorithm 48 chosen or specified by theminer system 22 and/or the blockchain network server 28. The minersystem 22 and/or the blockchain network server 28 may send a difficultyservice request to the difficulty server 160, and the difficulty servicerequest may specify the hash value(s) 60. The difficulty server 160executes the difficulty algorithm 48 using the hash value(s) 60 togenerate the difficulty 50. The difficulty server 160 sends the serviceresponse to the miner system 22, and the service response includes orspecifies the difficulty 50. The PoW server 124 may communicate with theblockchain network server 28 and the miner system 22 via thecommunications network 26. The PoW server 124 has a hardware processingelement (“P”) that executes the proof-of-work algorithm 52 stored in alocal memory device. The PoW service provider 120 (e.g., the PoW server124) may provide the PoW service 122 by executing the proof-of-workalgorithm 52 chosen or specified by the miner system 22 and/or theblockchain network server 28. The PoW server 124 sends the serviceresponse to the miner system 22, and the service response includes orspecifies the PoW result 42. The miner system 22 may compare any of thehash value(s) 60, the difficulty 50, and/or the PoW result 42 to theproof-of-work target scheme 34. If the proof-of-work target scheme 34 issatisfied, perhaps the miner system 22 is the first miner to have solvedthe puzzle 62.

Exemplary embodiments may be applied regardless of networkingenvironment. Exemplary embodiments may be easily adapted to stationaryor mobile devices having wide-area networking (e.g., 4G/LTE/5Gcellular), wireless local area networking (WI-FI®), near field, and/orBLUETOOTH® capability. Exemplary embodiments may be applied tostationary or mobile devices utilizing any portion of theelectromagnetic spectrum and any signaling standard (such as the IEEE802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/orthe ISM band). Exemplary embodiments, however, may be applied to anyprocessor-controlled device operating in the radio-frequency domainand/or the Internet Protocol (IP) domain. Exemplary embodiments may beapplied to any processor-controlled device utilizing a distributedcomputing network, such as the Internet (sometimes alternatively knownas the “World Wide Web”), an intranet, a local-area network (LAN),and/or a wide-area network (WAN). Exemplary embodiments may be appliedto any processor-controlled device utilizing power line technologies, inwhich signals are communicated via electrical wiring. Indeed, exemplaryembodiments may be applied regardless of physical componentry, physicalconfiguration, or communications standard(s).

Exemplary embodiments may utilize any processing component,configuration, or system. For example, the miner system 22 may utilizeany desktop, mobile, or server central processing unit or chipsetoffered by INTEL®, ADVANCED MICRO DEVICES®, ARM®, TAIWAN SEMICONDUCTORMANUFACTURING®, QUALCOMM®, or any other manufacturer. The miner system22 may even use multiple central processing units or chipsets, whichcould include distributed processors or parallel processors in a singlemachine or multiple machines. The central processing unit or chipset canbe used in supporting a virtual processing environment. The centralprocessing unit or chipset could include a state machine or logiccontroller. When any of the central processing units or chipsets executeinstructions to perform “operations,” this could include the centralprocessing unit or chipset performing the operations directly and/orfacilitating, directing, or cooperating with another device or componentto perform the operations.

Exemplary embodiments may packetize. When the blockchain network server28 and the miner system 22 communicate via the communications network26, the blockchain network server 28 and the miner system 22 maycollect, send, and retrieve information. The information may beformatted or generated as packets of data according to a packet protocol(such as the Internet Protocol). The packets of data contain bits orbytes of data describing the contents, or payload, of a message. Aheader of each packet of data may be read or inspected and containrouting information identifying an origination address and/or adestination address.

Exemplary embodiments may use any encryption or hashing function. Thereare many encryption algorithms and schemes, and exemplary embodimentsmay be adapted to execute or to conform to any encryption algorithmand/or scheme. In the blockchain environment 20, though, many readersmay be familiar with the various hashing algorithms, especially thewell-known SHA-256 hashing algorithm. The SHA-256 hashing algorithm actson any electronic data or information to generate a 256-bit hash valueas a cryptographic key. The key is thus a unique digital signature.However, there are many different hashing algorithms, and exemplaryembodiments may be adapted to execute or to conform to any hashingalgorithm, hashing family, and/or hashing scheme (e.g., Blake family, MDfamily, RIPE family, SHA family, CRC family).

The miner system 22 may store or request different software packages.The hashing algorithm 54 may be a software file, executable program,routine, module, programming code, or third-party service that hashesthe blockchain transactions 32 to generate the hash value(s) 60. Thedifficulty algorithm 48 may be a software file, executable program,routine, module, programming code, or third-party service that uses thehash value(s) 60 to generate the difficulty 50. The proof-of-work(“PoW”) algorithm 52 be a software file, executable program, routine,module, programming code, or third-party service that uses the hashvalue(s) 60 to generate the PoW result 42. The miner system 22 maydownload or otherwise acquire the hashing algorithm 54, the difficultyalgorithm 48, and/or the PoW algorithm 52 to provide mining operationsfor the blockchain transactions 32.

The blockchain environment 20 may flexibly switch or interchangeencryption, difficulty, and proof-of-work. Because the hashing algorithm54, the difficulty algorithm 48, and the proof-of-work algorithm 52 maybe separate software packages, the proof-of-work (“PoW”) target scheme34 and/or the blockchain environment 20 may mix-and-match the encryptionalgorithm 46, the difficulty algorithm 48, and the proof-of-workalgorithm 52. The blockchain environment 20 may thus easily evaluatedifferent combinations of the encryption algorithm 46, the difficultyalgorithm 48, and the proof-of-work algorithm 52 with little or nointra-algorithm or intra-application effect. The blockchain environment20 may mix-and-match encryption, difficulty, and proof-of-work.

FIGS. 22-31 illustrate mining specifications, according to exemplaryembodiments. When the miner system 22 communicates with the blockchainnetwork server 28, the blockchain network server 28 may specify theproof-of-work (“PoW”) target scheme 34 that is required by theblockchain environment 20. That is, when the miner system 22participates as a miner and mines or processes blockchainrecords/transactions, the miner system 22 may be required or instructedto use the particular hashing algorithm 54, the difficulty algorithm 48,and/or the proof-of-work algorithm 52 specified by the blockchainnetwork. For example, in order for the miner system 22 to be authorizedor recognized as a mining participant, the miner system 22 may berequired to download the client-side blockchain mining softwareapplication 196 that specifies or includes the hashing algorithm 54, thedifficulty algorithm 48, and/or the proof-of-work algorithm 52. Theclient-side blockchain mining software application 196 may thus compriseany software apps or modules, files, programming code, or instructionsrepresenting the hashing algorithm 54, the difficulty algorithm 48,and/or the proof-of-work algorithm 52.

FIGS. 23-25 illustrate an encryption identifier mechanism. FIG. 23illustrates the miner system 22 receiving the proof-of-work (“PoW”)target scheme 34 that is required by the blockchain environment 20. Inorder to reduce a memory byte size and/or programming line size of thePoW target scheme 34 and/or the client-side blockchain mining softwareapplication 196, exemplary embodiments may specify an encryptionidentifier (encryption “ID”) 200 associated with the blockchainnetwork's chosen or required encryption scheme. The encryptionidentifier 200 may be any alphanumeric combination, hash value, networkaddress, website, or other data/information that uniquely identifies thePoW target scheme 34 and/or the encryption algorithm 46 used by theblockchain environment 20. As FIG. 23 illustrates, the miner system 22may receive the encryption identifier 200 as a specification orparameter associated with the PoW target scheme 34 and/or the encryptionalgorithm 46. As FIG. 24 illustrates, though, the miner system 22 mayreceive a packetized message 202 from the blockchain network server 28,and a packet header and/or payload may specify or include the encryptionidentifier 200 as a data field, specification, or parameter. Again,because many or most blockchain networks use hashing as an encryptionmechanism, the encryption identifier 200 may specify, be assigned to, orbe associated with the hashing algorithm 54. The blockchain networkserver 28 may thus send the encryption identifier 200 (via thecommunications network 26) to the miner system 22. The encryptionidentifier 200 may be packaged as a downloadable component, parameter,or value with the client-side blockchain mining software application196. However, the encryption identifier 200 may additionally oralternatively be sent to the miner system 22 at any time via the message202. Because the encryption identifier 200 may be separately sent fromthe client-side blockchain mining software application 196, theencryption identifier 200 may be dynamically updated or changed withoutdownloading a new or updated client-side blockchain mining softwareapplication 196.

As FIG. 25 illustrates, exemplary embodiments may consult the electronicdatabase 70 of encryption algorithms. Once the miner system 22 receivesor determines the encryption identifier 200, the miner system 22 mayimplement the encryption scheme represented by the encryption identifier200. The miner system 22 may obtain, read, or retrieve the encryptionidentifier 200 specified by the client-side blockchain mining softwareapplication 196 and/or packet inspect the message 202 from theblockchain network server 28. Once the encryption identifier 200 isdetermined, the miner system 22 may identify the correspondingblockchain encryption scheme by querying the electronic database 70 ofencryption algorithms for the encryption identifier 200. FIG. 25illustrates the electronic database 70 of encryption algorithms locallystored in the memory device 38 of the miner system 22. The electronicdatabase 70 of encryption algorithms may store, reference, or associatethe encryption identifier 200 to its corresponding proof-of-work targetscheme 34 and/or encryption algorithm 46. The miner system 22 may thusperform or execute a database lookup for the encryption identifier 200to identify which proof-of-work target scheme 34 and/or encryptionalgorithm 46 is required for miners operating in the blockchainenvironment 20. The miner system 22 may then retrieve, call, and/orexecute the encryption algorithm 46 using the inputs 24 (such as theblockchain transactions 32), as this disclosure above explained (withreference to FIG. 7).

Exemplary embodiments may outsource encryption operations. When theminer system 22 determines the encryption identifier 200, thecorresponding blockchain encryption scheme may require or specify theencryption service provider 150 that provides the encryption service152. As FIG. 25 also illustrates, the electronic database 70 ofencryption algorithms may map or relate the encryption identifier 200 toits corresponding encryption service provider 150 that provides theencryption service 152. The miner system 22 may thus identify anencryption service resource 204 that provides the encryption service152. The encryption service resource 204, for example, may be anInternet protocol address, website/webpage, and/or uniform resourcelocator (URL) that is assigned to, or associated with, the encryptionservice provider 150 and/or the encryption service 152. The miner system22 may outsource or subcontract the inputs 24 (such as the blockchaintransactions 32) to the encryption service resource 204 (perhaps usingthe service request and service response mechanism explained withreference to FIG. 21).

Exemplary embodiments may thus be agnostic to hashing. The miner system22 may call, request, and/or execute any encryption scheme specified byany client, cryptographic coin, or blockchain network. The miner system22 may dynamically switch or mix-and-match different encryption schemes.Once the miner system 22 determines the proof-of-work target scheme 34,the encryption algorithm 46, the encryption service provider 150, theencryption service 152, the encryption identifier 200, and/or theencryption service resource 204, the miner system 22 may perform anyencryption scheme specified for the blockchain environment 20. Theblockchain environment 20 may dynamically change the encryption schemeat any time. The blockchain environment 20 may flexibly switch, change,and evaluate different encryption strategies, perhaps with little or noimpact or effect on difficulty and proof-of-work operations. Moreover,the miner system 22 may operate within or mine different blockchainenvironments 20 without specialized hardware rigs.

Exemplary embodiments improve computer functioning. Because exemplaryembodiments may only specify the encryption identifier 200, the memorybyte size consumed by the proof-of-work (“PoW”) target scheme 34 and/orthe client-side blockchain mining software application 196 is reduced.That is, the blockchain network server 28 need not send the entiresoftware program, code, or instructions representing the hashingalgorithm 54 used by the blockchain environment 20. The blockchainenvironment 20, the blockchain network server 28, and/or theproof-of-work (“PoW”) target scheme 34 need only specify much smallerbyte-sized data or information representing the encryption algorithm 46,the encryption service provider 150, the encryption service 152, theencryption identifier 200, and/or the encryption service resource 204.The blockchain environment 20 need not be burdened with conveying thehashing algorithm 54 to the miner system 22 and other mining nodes. Theblockchain environment 20 and the communications network 26 convey lesspacket traffic, so packet travel times and network latency are reduced.Moreover, especially if the miner system 22 outsources the hashingoperation, the miner system 22 is relieved from processing/executing thehashing algorithm 54 and consumes less of the electrical power. Again,then, a faster and more expensive graphics processor or even ASIC willnot speed up the hashing operation. The conventional central processingunit 36 is adequate, reduces costs, and promotes democratic mining.

FIGS. 26-28 illustrate illustrates a difficulty identifier mechanism.FIG. 26 illustrates the miner system 22 receiving the proof-of-work(“PoW”) target scheme 34 that is required by the blockchain environment20. In order to reduce a memory byte size and/or programming line sizeof the PoW target scheme 34 and/or the client-side blockchain miningsoftware application 196, exemplary embodiments may specify a difficultyidentifier (difficulty “ID”) 210 associated with the blockchainnetwork's chosen or required difficulty scheme. The difficultyidentifier 210 may be any alphanumeric combination, hash value, networkaddress, website, or other data/information that uniquely identifies thePoW target scheme 34 and/or the difficulty algorithm 48 used by theblockchain environment 20. As FIG. 26 illustrates, the miner system 22may receive the difficulty identifier 210 as a specification orparameter associated with the PoW target scheme 34 and/or the difficultyalgorithm 48. As FIG. 27 illustrates, though, the miner system 22 mayreceive the packetized message 202 from the blockchain network server28, and a packet header and/or payload may specify or include thedifficulty identifier 210 as a data field, specification, or parameter.The blockchain network server 28 may thus send the difficulty identifier210 (via the communications network 26) to the miner system 22. Thedifficulty identifier 210 may be packaged as a downloadable component,parameter, or value with the client-side blockchain mining softwareapplication 196. However, the difficulty identifier 210 may additionallyor alternatively be sent to the miner system 22 at any time via themessage 202. Because the difficulty identifier 210 may be separatelysent from the client-side blockchain mining software application 196,the difficulty identifier 210 may be dynamically updated or changedwithout downloading a new or updated client-side blockchain miningsoftware application 196.

As FIG. 28 illustrates, exemplary embodiments may consult the electronicdatabase 74 of difficulty algorithms. Once the miner system 22 receivesor determines the difficulty identifier 210, the miner system 22 mayimplement the difficulty scheme represented by the difficulty identifier210. The miner system 22 may obtain, read, or retrieve the difficultyidentifier 210 specified by the client-side blockchain mining softwareapplication 196 and/or packet inspect the message 202 from theblockchain network server 28. Once the difficulty identifier 210 isdetermined, the miner system 22 may identify the correspondingblockchain difficulty scheme by querying the electronic database 74 ofdifficulty algorithms for any query parameter (such as the difficultyidentifier 210). FIG. 28 illustrates the electronic database 74 ofdifficulty algorithms locally stored in the memory device 38 of theminer system 22. The electronic database 74 of difficulty algorithms maystore, reference, or associate the difficulty identifier 210 to itscorresponding proof-of-work target scheme 34 and/or difficulty algorithm48. The miner system 22 may thus perform or execute a database lookupfor the difficulty identifier 210 to identify which proof-of-work targetscheme 34 and/or difficulty algorithm 48 is required for minersoperating in the blockchain environment 20. The miner system 22 may thenretrieve, call, and/or execute the difficulty algorithm 48 using thehash value(s) 60, as this disclosure above explained (with reference toFIG. 8).

Exemplary embodiments may outsource difficulty operations. When theminer system 22 determines the difficulty identifier 210, thecorresponding blockchain difficulty scheme may require or specify thedifficulty service provider 156 that provides the difficulty service158. As FIG. 28 also illustrates, the electronic database 74 ofdifficulty algorithms may map or relate the difficulty identifier 210 toits corresponding difficulty service provider 156 that provides thedifficulty service 158. The miner system 22 may thus identify adifficulty service resource 212 that provides the difficulty service158. The difficulty service resource 212, for example, may be anInternet protocol address, website/webpage, and/or uniform resourcelocator (URL) that is assigned to, or associated with, the difficultyservice provider 156 and/or the difficulty service 158. The miner system22 may outsource or subcontract the hash value(s) 60 to the difficultyservice resource 212 (perhaps using the service request and serviceresponse mechanism explained with reference to FIG. 21).

Exemplary embodiments may thus be agnostic to difficulty. The minersystem 22 may call, request, and/or execute any difficulty schemespecified by any client, cryptographic coin, or blockchain network. Theminer system 22 may dynamically switch or mix-and-match differentdifficulty schemes. Once the miner system 22 determines theproof-of-work target scheme 34, the difficulty algorithm 48, thedifficulty service provider 156, the difficulty service 158, thedifficulty identifier 210, and/or the difficulty service resource 212,the miner system 22 may perform any difficulty scheme specified for theblockchain environment 20. The blockchain environment 20 may dynamicallychange the difficulty scheme at any time. The blockchain environment 20may flexibly switch, change, and evaluate different difficultystrategies, perhaps with little or no impact or effect on hashing andproof-of-work operations. Moreover, the miner system 22 may operatewithin or mine different blockchain environments 20 without specializedhardware rigs.

Exemplary embodiments improve computer functioning. Because exemplaryembodiments may only specify the difficulty identifier 210, the memorybyte size consumed by the proof-of-work (“PoW”) target scheme 34 and/orthe client-side blockchain mining software application 196 is reduced.That is, the blockchain network server 28 need not send the entiresoftware program, code, or instructions representing the difficultyalgorithm 48 used by the blockchain environment 20. The blockchainenvironment 20, the blockchain network server 28, and/or theproof-of-work (“PoW”) target scheme 34 need only specify much smallerbyte-sized data or information representing the difficulty algorithm 48,the difficulty service provider 156, the difficulty service 158, thedifficulty identifier 210, and/or the difficulty service resource 212.The blockchain environment 20 need not be burdened with conveying thedifficulty algorithm 48 to the miner system 22 and other mining nodes.The blockchain environment 20 and the communications network 26 conveyless packet traffic, so packet travel times and network latency arereduced. Moreover, especially if the miner system 22 outsources thedifficulty operation, the miner system 22 is relieved fromprocessing/executing the difficulty algorithm 48 and consumes less ofthe electrical power. Again, then, a faster and more expensive graphicsprocessor or even ASIC will not speed up the difficulty operation. Theconventional central processing unit 36 is adequate, reduces costs, andpromotes democratic mining.

FIGS. 29-31 illustrate illustrates a proof-of-work (“PoW”) identifiermechanism. FIG. 29 illustrates the miner system 22 receiving theproof-of-work (“PoW”) target scheme 34 that is required by theblockchain environment 20. In order to reduce a memory byte size and/orprogramming line size of the PoW target scheme 34 and/or the client-sideblockchain mining software application 196, exemplary embodiments mayspecify a PoW identifier 214 associated with the blockchain network'schosen or required PoW scheme. The PoW identifier 214 may be anyalphanumeric combination, hash value, network address, website, or otherdata/information that uniquely identifies the PoW target scheme 34and/or the PoW algorithm 52 used by the blockchain environment 20. AsFIG. 29 illustrates, the miner system 22 may receive the PoW identifier214 as a specification or parameter associated with the PoW targetscheme 34 and/or the PoW algorithm 52. As FIG. 30 illustrates, though,the miner system 22 may receive the packetized message 202 from theblockchain network server 28, and a packet header and/or payload mayspecify or include the PoW identifier 214 as a data field,specification, or parameter. The blockchain network server 28 may thussend the PoW identifier 214 (via the communications network 26) to theminer system 22. The PoW identifier 214 may be packaged as adownloadable component, parameter, or value with the client-sideblockchain mining software application 196. However, the PoW identifier214 may additionally or alternatively be sent to the miner system 22 atany time via the message 202. Because the PoW identifier 214 may beseparately sent from the client-side blockchain mining softwareapplication 196, the PoW identifier 214 may be dynamically updated orchanged without downloading a new or updated client-side blockchainmining software application 196.

As FIG. 31 illustrates, exemplary embodiments may consult the electronicdatabase 78 of PoW algorithms. Once the miner system 22 receives ordetermines the PoW identifier 214, the miner system 22 may implement theproof-of-work scheme represented by the PoW identifier 214. The minersystem 22 may obtain, read, or retrieve the PoW identifier 214 specifiedby the client-side blockchain mining software application 196 and/orpacket inspect the message 202 from the blockchain network server 28.Once the PoW identifier 214 is determined, the miner system 22 mayidentify the corresponding blockchain proof-of-work scheme by queryingthe electronic database 78 of PoW algorithms for any query parameter(such as the PoW identifier 214). FIG. 31 illustrates the database 78 ofPoW algorithms locally stored in the memory device 38 of the minersystem 22. The electronic database 78 of PoW algorithms may store,reference, or associate the PoW identifier 214 to its correspondingproof-of-work target scheme 34 and/or difficulty algorithm 48. The minersystem 22 may thus perform or execute a database lookup for the PoWidentifier 214 to identify which proof-of-work target scheme 34 and/orPoW algorithm 52 is required for miners operating in the blockchainenvironment 20. The miner system 22 may then retrieve, call, and/orexecute the PoW algorithm 52 using the hash value(s) 60, as thisdisclosure above explained (with reference to FIG. 9).

Exemplary embodiments may outsource difficulty operations. When theminer system 22 determines the PoW identifier 214, the correspondingblockchain proof-of-work scheme may require or specify the PoW serviceprovider 120 that provides the PoW service 122. As FIG. 31 alsoillustrates, the electronic database 78 of PoW algorithms may map orrelate the PoW identifier 214 to its corresponding PoW service provider120 and PoW service 122. The miner system 22 may thus identify a PoWservice resource 216 that provides the PoW service 122. The PoW serviceresource 216, for example, may be an Internet protocol address,website/webpage, and/or uniform resource locator (URL) that is assignedto, or associated with, the PoW service provider 120 and/or PoW service122. The miner system 22 may outsource or subcontract the hash value(s)60 to the PoW service resource 216 (perhaps using the service requestand service response mechanism explained with reference to FIG. 21).

Exemplary embodiments may thus be agnostic to proof-of-work. The minersystem 22 may call, request, and/or execute any proof-of-work schemespecified by any client, cryptographic coin, or blockchain network. Theminer system 22 may dynamically switch or mix-and-match differentproof-of-work schemes. Once the miner system 22 determines theproof-of-work target scheme 34, the PoW algorithm 52, the PoW serviceprovider 120, the PoW service 122, the PoW identifier 214, and/or thePoW service resource 216, the miner system 22 may perform anyproof-of-work scheme specified for the blockchain environment 20. Theblockchain environment 20 may dynamically change the proof-of-workscheme at any time. The blockchain environment 20 may flexibly switch,change, and evaluate different proof-of-work strategies, perhaps withlittle or no impact or effect on hashing and difficulty operations.Moreover, the miner system 22 may operate within or mine differentblockchain environments 20 without specialized hardware rigs.

Exemplary embodiments improve computer functioning. Because exemplaryembodiments may only specify the PoW identifier 214, the memory bytesize consumed by the proof-of-work (“PoW”) target scheme 34 and/or theclient-side blockchain mining software application 196 is reduced. Thatis, the blockchain network server 28 need not send the entire softwareprogram, code, or instructions representing the PoW algorithm 52 used bythe blockchain environment 20. The blockchain environment 20, theblockchain network server 28, and/or the proof-of-work (“PoW”) targetscheme 34 need only specify much smaller byte-sized data or informationrepresenting the PoW algorithm 52, the PoW service provider 120, the PoWservice 122, the PoW identifier 214, and/or the PoW service resource216. The blockchain environment 20 need not be burdened with conveyingthe PoW algorithm 52 to the miner system 22 and other mining nodes. Theblockchain environment 20 and the communications network 26 convey lesspacket traffic, so packet travel times and network latency are reduced.Moreover, especially if the miner system 22 outsources the proof-of-workoperation, the miner system 22 is relieved from processing/executing thePoW algorithm 52 and consumes less of the electrical power. Again, then,a faster and more expensive graphics processor or even ASIC will notspeed up the difficulty operation. The conventional central processingunit 36 is adequate, reduces costs, and promotes democratic mining.

FIG. 32 illustrates remote retrieval, according to exemplaryembodiments. After the miner system 22 determines the proof-of-work(“PoW”) target scheme 34 that is required by the blockchain environment20, the miner system 22 may acquire or download the encryption algorithm46, the difficulty algorithm 48, and/or the PoW algorithm 52. Forexample, the miner system 22 may determine the encryption identifier 200(as this disclosure above explains) and send a query to the encryptionserver 154. The query specifies the encryption identifier 200. When theencryption server 154 receives the query, the encryption server 154 mayquery the database 70 of encryption algorithms for the encryptionidentifier 200. The encryption server 154 may locally store the database70 of encryption algorithms and function as a networked encryptionresource for clients. The encryption server 154 identifies and/orretrieves the corresponding encryption algorithm 46. The encryptionserver 154 sends a query response to the miner system 22, and the queryresponse specifies or includes the corresponding encryption algorithm46. The miner system 22 may then execute the encryption algorithm 46, asabove explained.

The miner system 22 may remotely retrieve the difficulty algorithm 48.After the miner system 22 determines the proof-of-work (“PoW”) targetscheme 34 that is required by the blockchain environment 20, the minersystem 22 may acquire or download the difficulty algorithm 48. Forexample, the miner system 22 may determine the difficulty identifier 210(as this disclosure above explains) and send a query to the difficultyserver 160. The query specifies the difficulty identifier 210. When thedifficulty server 160 receives the query, the difficulty server 160 mayquery the database 74 of difficulty algorithms for the difficultyidentifier 210. The difficulty server 160 may locally store the database74 of difficulty algorithms and function as a networked difficultyresource for clients. The difficulty server 160 identifies and/orretrieves the corresponding difficulty algorithm 48. The difficultyserver 160 sends a query response to the miner system 22, and the queryresponse specifies or includes the corresponding difficulty algorithm48. The miner system 22 may then execute the difficulty algorithm 48, asabove explained.

The miner system 22 may remotely retrieve the PoW algorithm 52. Afterthe miner system 22 determines the proof-of-work (“PoW”) target scheme34 that is required by the blockchain environment 20, the miner system22 may acquire or download the PoW algorithm 52. For example, the minersystem 22 may determine the PoW identifier 214 (as this disclosure aboveexplains) and send a query to the PoW server 124. The query specifiesthe PoW identifier 214. When the PoW server 124 receives the query, thePoW server 124 may query the database 78 of PoW algorithms for the PoWidentifier 214. The PoW server 124 may locally store the database 78 ofPoW algorithms and function as a networked proof-of-work resource forclients. The PoW server 124 identifies and/or retrieves thecorresponding PoW algorithm 52. The PoW server 124 sends a queryresponse to the miner system 22, and the query response specifies orincludes the corresponding PoW algorithm 52. The miner system 22 maythen execute the PoW algorithm 52, as above explained.

FIGS. 33-34 further illustrate the bit shuffle operation 92, accordingto exemplary embodiments. The difficulty algorithm 48 and/or theproof-of-work algorithm 52 may perform the bit shuffle operation 92 toconduct any difficulty and/or proof-of-work. After the hashing algorithm54 generates the hash value(s) 60 (as this disclosure above explains),exemplary embodiments may use the database table 90 to further deterGPU/ASIC usage. The difficulty algorithm 48 and/or the proof-of-workalgorithm 52 may implement the bit shuffle operation 92 on the hashvalue(s) 60. As FIG. 34 illustrates, suppose the hash value 60 isrepresented by a sequence or series of 256 bit values. The difficultyalgorithm 48 and/or the proof-of-work algorithm 52 may select anarbitrary portion or number 220 of the bit values. The difficultyalgorithm 48 and/or the proof-of-work algorithm 52, for example, maycall, use, or execute a random number generator (RNG) 222 to generateone or more random numbers 224. As an example, a first random number 224may be used to select a random entry 94 in the database table 90. Thedifficulty algorithm 48 and/or the proof-of-work algorithm 52 may thenquery the database table 90 for the random entry 94 andidentify/retrieve the corresponding random bits 96. The difficultyalgorithm 48 and/or the proof-of-work algorithm 52 may then select andreplace the arbitrary portion or number 220 of the bit values in thehash value 60 with the random bits retrieved from the entry 94 in thedatabase table 90. The bit shuffle operation 92 thus converts the hashvalue 60 and generates a resulting randomized hash value 226. Thedifficulty algorithm 48 and/or the proof-of-work algorithm 52 mayinstruct or cause the miner system to repeat the bit shuffle operation92 as many times as desired. The randomized hash value 226 may, or maynot, have the same number of 256 bit values. The randomized hash value226 may have less than, or more than, 256 bit values. The randomizedhash value 226 may have an arbitrary number of bit values. Once thespecified or required number of bit shuffle operations 92 is complete,the difficulty algorithm 48 and/or the proof-of-work algorithm 52 mayinstruct or cause the miner system to determine the difficulty 50 and/orthe PoW result 42 (as this disclosure above explains).

FIGS. 35-36 further illustrate the database table 90, according toexemplary embodiments. Exemplary embodiments may autonomously orautomatically adjust the table byte size 102 (in bits/bytes) of thedatabase table 90 to exceed the storage capacity or cache byte size 104of the on-board processor cache memory 100. The client-side blockchainmining application 196, for example, may query the CPU 36 to determinethe storage capacity or cache byte size 104 of the processor cachememory 100. If the table byte size 102 consumed by the database table 90exceeds the storage capacity or cache byte size 104 of the processorcache memory 100, then perhaps no action or resolution is required. Thatis, the database table 90 requires more bytes or space than allocatedto, or available from, the processor cache memory 100(integrated/embedded L1, L2, and L3 SRAM/DRAM cache memory). Any cacheread/write operation 230 will invalidate, thus forcing the processingcomponent (whether a GPU, ASIC, or the CPU 36) to incur a cache miss 232and endure the cache latency 234 of requesting and writing blocks ofdata via the much-slower bus from the system/main memory 38. Theprocessing component (whether a GPU, ASIC, or the CPU 36) stalls, thusnegating the use of a faster GPU or ASIC.

Exemplary embodiments may auto-size the database table 90. When theclient-side blockchain mining application 196 determines the storagecapacity or cache byte size 104 of the processor cache memory 100, theclient-side blockchain mining application 196 may compare the storagecapacity or cache byte size 104 to the table byte size 102 of thedatabase table 90. The storage capacity or cache byte size 104 of theprocessor cache memory 100, for example, may be subtracted from thetable byte size 102 of the database table 90. If the resulting value (inbits/bytes) is positive (greater than zero), then the database table 90exceeds the storage capacity or cache byte size 104 of the processorcache memory 100. The client-side blockchain mining application 196 maythus determine a cache deficit 236, ensuring the cache miss 232 and thecache latency 234.

Exemplary embodiments, however, may determine a cache surplus 238. Ifthe resulting value (in bits/bytes) is zero or negative, then thedatabase table 90 is less than the storage capacity or cache byte size104 of the processor cache memory 100. Whatever the processing component(whether a GPU, ASIC, or the CPU 36), some or even all of the databasetable 90 could be stored and retrieved from the processor cache memory100, thus giving an advantage to a faster processing component. Theclient-side blockchain mining application 196 may thus increase thetable byte size 102 of the database table 90. The client-side blockchainmining application 196, for example, may add one (1) or more additionaldatabase rows 240 and/or one (1) or more additional database columns242. The client-side blockchain mining application 196 may increase thetable byte size 102 of the database table 90 by adding additionalentries 94, with each added entry 94 specifying more random bits 96. Asan example, the client-side blockchain mining application 196 may call,use, or execute the random number generator 222 to generate the randomnumber 224 and then add the additional database row(s) 240 and/oradditional database column(s) 242 according to the random number 224.Exemplary embodiments may thus continually or periodically monitor thestorage capacity or cache byte size 104 of the processor cache memory100 and the table byte size 102 of the database table 90. The cachesurplus 238 may trigger a resizing operation to ensure the databasetable 90 always exceeds the processor cache memory 100.

The database table 90 may be large. The above examples only illustrateda simple configuration of a few database entries 94. In actual practice,though, the database table 90 may have hundreds, thousands, or evenmillions of the rows and columns, perhaps producing hundreds, thousands,millions, or even billions of database entries 94. Exemplary embodimentsmay repeatedly perform the bit shuffle operation 92 to suit anydifficulty or proof-of-work strategy or scheme. The proof-of-work targetscheme 34, the difficulty algorithm 48, and/or the proof-of-workalgorithm 52 may each specify a minimum and/or a maximum number of bitshuffle operations that are performed.

Exemplary embodiments may use the XOR/Shift random number generator(RNG) 222 coupled with the lookup database table 90 of randomized setsof bytes. The database table 90 may have any number of 256 byte tablescombined and shuffled into one large byte lookup table. Exemplaryembodiments may then index into this large table to translate the statebuilt up while hashing into deterministic but random byte values. Usinga 1GB lookup table results in a RAM Hash PoW algorithm that spends over90% of its execution time waiting on memory (RAM) than it does computingthe hash. This means far less power consumption, and ASIC and GPUresistance. The ideal platform for PoW using a RAM Hash is a SingleBoard Computer like a. Raspberry PI 4 with 2 GB of memory.

Any or all parameters may be specified. The size of the database table90 may be specified in bits for the index, the seed used to shuffle thelookup table, the number of rounds to shuffle the table, and the size ofthe resulting hash. Because the LXRHash is parameterized in this way, ascomputers get faster and larger memory caches, the LXRHash can be set touse 2 GB or 16 GB or more. The Memory bottleneck to computation is mucheasier to manage than attempts to find computational algorithms thatcannot be executed faster and cheaper with custom hardware, or specialtyhardware like GPUs. Very large lookup tables will blow the memory cacheson pretty much any processor or computer architecture. The size of thedatabase table 90 can be increased to counter improvements in memorycaching. The number of bytes in the resulting hash can be increased formore security (greater hash space), without significantly moreprocessing time. LXRHash may even be fast by using small lookup tables.ASIC implementations for small tables would be very easy and very fast.LXRHash only uses iterators (for indexing) shifts, binary ANDs and XORs,and random byte lookups. The use case for LXTHash is Proof of Work(PoW), not cryptographic hashing.

The database table 90 may have equal numbers of every byte value, andshuffled deterministically. When hashing, the bytes from the source dataare used to build offsets and state that are in turn used to map thenext byte of source. In developing this hash, the goal was to producevery randomized hashes as outputs, with a strong avalanche response toany change to any source byte. This is the prime requirement of PoW.Because of the limited time to perform hashing in a blockchain,collision avoidance is important but not critical. More critical isensuring engineering the output of the hash isn't possible. Exemplaryembodiments yield some interesting qualities. For example, the databasetable 90 may be any size, so making a version that is ASIC resistant ispossible by using very big lookup tables. Such tables blow the processorcaches on CPUs and GPUs, making the speed of the hash dependent onrandom access of memory, not processor power. Using 1 GB lookup table, avery fast ASIC improving hashing is limited to about ˜10% of thecomputational time for the hash. 90% of the time hashing isn't spent oncomputation but is spent waiting for memory access. At smaller lookuptable sizes, where processor caches work, LXRHash can be modified to bevery fast. LXRHash would be an easy ASIC design as it only usescounters, decrements. XORs, and shifts. The hash may be altered bychanging the size of the lookup table, the seed, size of the hashproduced. Change any parameter and you change the space from whichhashes are produced. The Microprocessor in most computer systemsaccounts for 10× the power requirements of memory. If we consider PoW ona device over time, then LXRHash is estimated to reduce powerrequirements by about a factor of 10.

Testing has revealed some optimizations. LXRHash is comparatively slowby design (to make PoW CPU bound), but quite a number of use cases don'tneed PoW, but really just need to validate data matches the hash. Sousing LXRHash as a hashing function isn't as desirable as simply usingit as a POW function. The somewhat obvious conclusion is that in fact wecan use Sha256 as the hash function for applications, and only use theLXR approach as a PoW measure. So in this case, what we do is change howwe compute the PoW of a hash. So instead of simply looking at the highorder bits and saying that the greater the value the greater thedifficulty (or the lower the value the lower the difficulty) we insteaddefine an expensive function to calculate the PoW.

Exemplary embodiments may break out PoW measures from cryptographichashes. The advantage here is that what exactly it means to weigh PoWbetween miners can be determined apart from the hash that secures ablockchain. Also, a good cryptographic hash provides a much better basefrom which to randomize PoW even if we are going to use a 1 GB byte mapto bound performance by DRAM access. And we could also use past mining,reputation, staking, or other factors to add to PoW at this point.

PoW may be represented as a nice standard sized value. Because exemplaryembodiments may use a function to compute the PoW, we can also easilystandardize the size of the difficulty. Since bytes that are all 0xFF orall 0x00 are pretty much wasted, we can simply count them and combinethat count with the following bytes. This encoding is compact and easilycompared to other difficulties in a standard size with plenty ofresolution. So with PoW represented as a large number, the bigger themore difficult, the following rules may be followed. Where bit 0 is mostsignificant, and bit 63 is least significant:

-   -   Bits 0-3 Count of leading 0xFF bytes; and    -   Bits 4-63 bits of the following bytes.

For example, given the hash

-   -   ffffff7312334c442bf42625f7856fe0d50e4aa45c98d7a391c016b89e242d94,        the difficulty is 37312334c442bf42. The computation counts the        leading bytes with a value of 0xFF, then calculates the uint64        value of the next 8 bytes. The count is combined with the        following bytes by shifting the 8 bytes right by 4, and adding        the count shifted left by 60. As computing power grows, more        significant bits of the hash can be used to represent the        difficulty. At a minimum, difficulty is represented by 4 bits        0x0 plus the following 0±60 bits=>60 bits of accuracy. At the        maximum, difficulty is represented by 4 bits 0xF plus the        following 60 bits=>120±60=180 bits of accuracy.

Sha256 is very well tested as a cryptographic function, with excellentwaterfall properties (meaning odds are very close to 50% that any changein the input will flit any particular bit in the resulting hash).Hashing the data being mined by the miners is pretty fast. If anapplication chooses to use a different hashing function, that's okay aswell.

FIGS. 37-40 illustrate a table identifier mechanism, according toexemplary embodiments. When the miner system 22 communicates with theblockchain network server 28, the blockchain network server 28 mayspecify the proof-of-work (“PoW”) target scheme 34 and/or the databasetable 90 that is required by the blockchain environment 20. For example,in order to reduce a memory byte size and/or programming line size ofthe proof-of-work (“PoW”) target scheme 34 and/or the client-sideblockchain mining software application 196, exemplary embodiments mayonly specify a table identifier 250 associated with the blockchainnetwork's chosen or required difficulty and proof-of-work scheme. Thetable identifier 250 may be any alphanumeric combination, hash value,network address, website, or other data/information that uniquelyidentifies the database table 90 used by the blockchain environment 20.The blockchain network server 28 may thus send the table identifier 250(via the communications network 26) to the miner system 22. The tableidentifier 250 may be packaged as a downloadable component, parameter,or value with the client-side blockchain mining software application196. However, the table identifier 250 may additionally or alternativelybe sent to the miner system 22, such as the packetized message 202 thatincludes or specifies the table identifier 250 (explained with referenceto FIGS. 22-31). Because the table identifier 250 may be separately sentfrom the client-side blockchain mining software application 196, thetable identifier 250 may be dynamically updated or changed withoutdownloading a new or updated client-side blockchain mining softwareapplication 196.

Exemplary embodiments may consult an electronic database 252 of tables.When the miner system 22 receives the table identifier 250, the minersystem 22 may use, call, and/or implement the database table 90represented by the table identifier 250. The miner system 22 may obtain,read, or retrieve the table identifier 250 specified by the client-sideblockchain mining software application 196. The miner system 22 mayadditionally or alternatively inspect, read, or retrieve the tableidentifier 250 from the message 202. Once the table identifier 250 isdetermined, the miner system 22 may identify the corresponding databasetable 90 by querying the database 252 of tables for the table identifier250. FIG. 37 illustrates the electronic database 252 of tables locallystored in the memory device 38 of the miner system 22. The database 252of tables stores, references, or associates the table identifier 250and/or the proof-of-work target scheme 34 to the corresponding databasetable 90. The miner system 22 may thus identify and/or retrieve thedatabase table 90. The miner system 22 may then execute the difficultyalgorithm 48 and/or the proof-of-work algorithm using the entriesspecified by the database table 90 (as this disclosure above explains).

FIG. 38 illustrates remote retrieval. FIG. 38 illustrates the database252 of tables remotely stored by a table server 254 and accessed via thecommunications network 26. The table server 254 may be the onlyauthorized source for the database table 90. The table server 254 maythus operate within the blockchain environment 20 and provide thelatest/current database table 90 for all miners in the blockchainnetwork. The table server 254, however, may be operated on behalf of anauthorized third-party vendor or supplier that provides the databasetable 90 for all miners in the blockchain network. Once the miner system22 determines the table identifier 250, the miner system 22 may send aquery to the network address associated with or assigned to the tableserver 254. The query specifies the table identifier 250. When the tableserver 254 receives the query, the table server 254 queries theelectronic database 252 of tables for the table identifier 250 specifiedby the query. The table server 254 has a hardware processor and memorydevice (not shown for simplicity) that stores and executes a queryhandler software application. The query handler software applicationcauses the table server 254 to perform a database lookup operation. Thetable server 254 identifies the corresponding database table 90 byquerying the database 252 of tables for the table identifier 250. Thetable server 254 generates and sends a query response to the networkaddress associated with or assigned to the miner system 22, and thequery response includes or specifies the database table 90 that isassociated with the table identifier 250. The miner system 22 may thusidentify, download, and/or retrieve the database table 90.

Because the database 252 of tables may store or reference many differentdatabase tables, exemplary embodiments may dynamically switch or changethe database table 90 to suit any objective or performance criterion.Exemplary embodiments may thus need only specify the table identifier250, and the table identifier 250 may be dynamically changed at anytime. The blockchain environment 20 may flexibly switch, change, andevaluate different database tables, merely by changing or modifying thetable identifier 250. The blockchain network may thus experiment withdifferent database tables, different difficulty algorithms 48, and/ordifferent proof-of-work algorithms 52 with little or no impact or effecton hashing. Should an experimental scheme prove or become undesirable,for whatever reason(s), the blockchain environment 20 (such as theblockchain network server 28) may distribute, assign, or restore anew/different table identifier 250 (perhaps by updating the client-sideblockchain mining software application 196 and/ordistributing/broadcasting the message 202, as this disclosure aboveexplains). The blockchain environment 20 may thus dynamically change thedatabase table 90, which may concomitantly change the difficultyalgorithm 48 and/or the proof-of-work algorithm 52, for quick evaluationand/or problem resolution.

FIG. 39 further illustrates table services. Here the table server 254may serve different blockchain environments 20. For example, the tableserver 254 may server miners 22 a operating in blockchain environment 20a. The table server 254 may also server miners 22 b operating inblockchain environment 20 b. The table server 254 may thus be operatedon behalf of a table service provider 256 that provides a table service258 to clients and blockchain networks. The table service provider 256may receive, generate, and/or store different database tables 90,perhaps according to a client's or a blockchain's specification. Eachdifferent table 90 may have its corresponding unique table identifier250. So, whatever the proof-of-work (“PoW”) target scheme (e.g., 34 aand 34 b) and/or the blockchain environment 20 a-b, the table server 254may offer and provide the corresponding database table 90. The tableservice provider 256 and/or the table server 254 may thus be anauthorized provider or participant in the blockchain environments 20a-b. A first miner system 22 a, for example, operating in the blockchainenvironment 20 a, may request and retrieve the database table 90 a thatcorresponds to the proof-of-work (“PoW”) target scheme 34 a. Adifferent, second system 22 b, operating in the blockchain environment20 b, may request and retrieve the database table 90 b that correspondsto the proof-of-work (“PoW”) target scheme 34 b. Miners may query thetable server 254 (perhaps by specifying the corresponding table ID 250)and retrieve the corresponding database table 90. The table serviceprovider 256 may thus specialize in randomized/cryptographic databasetables, and the table server 254 may serve different blockchainnetworks.

FIG. 40 further illustrates table services. The blockchain environment20 and/or the miner system 22 may outsource the bit shuffle operation 92to the table service provider 256. Once the miner system 22 determinesor receives the hash value(s) 60 (generated by the hashing algorithm54), the miner system 22 may outsource or subcontract the bit swapoperation 92 to the table server 254. The client-side blockchain miningsoftware application 196 may thus cause or instruct the miner system 22to generate a bit shuffle service request that is sent to the tableservice provider 256 (such as the IP address assigned to the tableserver 254). The bit shuffle service request may specify or include thehash values 60. The bit shuffle service request may additionally oralternatively specify or include the table identifier 250. The bitshuffle service request may additionally or alternatively specify orinclude a website, webpage, network address location, or server fromwhich the hash values 60 may be downloaded, retrieved, or obtained toperform the bit shuffle operation 92. While the table service provider256 may utilize any mechanism to provide the bit shuffle operation 92,FIG. 40 illustrates a vendor's server/client relationship. The minersystem 22 sends the bit shuffle service request to the table server 254that is operated on behalf of the table service provider 256. When thetable server 254 receives the bit shuffle service request, the tableserver 254 may query the database 252 of tables for the table identifier250 specified by the bit shuffle service request. The table server 254identifies the corresponding database table 90. The table server 254performs the bit shuffle operation 92 using the hash value(s) 60specified by, or referenced by, the bit shuffle service request. Thetable server 254 generates and sends a service result to the networkaddress associated with or assigned to the miner system 22, and theservice result includes or specifies data or information representingthe randomized hash value(s) 226. The miner system 22 may then execute,or outsource, the difficulty algorithm 48 and/or the proof-of-workalgorithm 52 using the randomized hash value(s) 226 (as this disclosureabove explained).

Exemplary embodiments improve computer functioning. The database table90 adds cryptographic security by further randomizing the hash value(s)60 generated by the hashing algorithm 54. Moreover, because the databasetable 90 may be remotely located and accessed, exemplary embodiments mayonly specify the table identifier 250. The memory byte size consumed bythe proof-of-work (“PoW”) target scheme 34 and/or the client-sideblockchain mining software application 196 is reduced. That is, theblockchain network server 28 need not send the entire software program,code, or instructions representing the database table 90 used by theblockchain environment 20. The blockchain environment 20, the blockchainnetwork server 28, and/or the proof-of-work (“PoW”) target scheme 34need only specify the much smaller byte-sized table identifier 250. Theblockchain environment 20 need not be burdened with conveying thedatabase table 90 to the miner system 22 and to other mining nodes. Theblockchain environment 20 and the communication network 26 convey lesspacket traffic, so packet travel times and network latency are reduced.Moreover, especially if the miner system 22 outsources table operations,the miner system 22 is relieved from processing/executing the bit swapoperation 92 and consumes less electrical power. Again, then, a fasterand more expensive graphics processor or even ASIC will not speed up theproof-of-work operation. The conventional central processing unit 36 isadequate, reduces costs, and promotes democratic mining.

Exemplary embodiments improve cryptographic security. If the blockchainenvironment 20, the proof-of-work (“PoW”) target scheme 34 and/or theclient-side blockchain mining software application 196 specifies use ofthe database table 90, only authorized miners may have access to theactual entries referenced by the database table 90. That is, if minersystem 22 is required to perform, implement, or even execute the bitshuffle operation 92, the miner system 22 must have access to thecorrect database table 90. An unauthorized or rogue entity, in otherwords, likely could not perform the bit shuffle operation 92 withoutaccess to the correct database table 90. Moreover, if the bit shuffleoperation 92 is remotely performed from the miner system 22 (such as bythe table server 254, as above explained), perhaps not even theauthorized miner system 22 need have access to the database table 90.So, even if the miner system 22 is authorized to mine or processblockchain transactions 32 in the blockchain environment 20, theauthorized miner system 22 may still be blind to the database table 90.The authorized miner system 22, in other words, is operationally relianton the table server 254 to perform the bit shuffle operation 92 that maybe required for the difficulty algorithm 48 and/or for the proof-of-workalgorithm 52. The miner system 22 simply cannot solve the mathematicalpuzzle 62 without the table service 258 provided by the table server254. The database table 90 may thus be proprietary to the blockchainenvironment 20, but, unknown and unavailable to even the authorizedminer system 22 for added cryptographic security.

FIG. 41 illustrates agnostic blockchain mining, according to exemplaryembodiments. As the reader may now realize, the miner system 22 may beagnostic to the blockchain environment 20. Because the miner system 22may be agnostic to encryption, difficulty, and proof-of-work operations,the miner system 22 may process or mine the blockchain transactions 32in multiple blockchain environments 20. That is, because theconventional CPU 36 is adequate for mining blockchain transactions 32,no specialized ASIC is required for any particular blockchainenvironment 20. The miner system 22 may thus participate in multipleblockchain environments 20 and potentially earn multiple rewards. Theminer system 22, for example, may participate in the blockchainenvironment 22 a and mine the blockchain transactions 32 a sent from theblockchain network server 28 a to authorized miners in blockchainnetwork 260 a. The miner system 22 may thus mine the blockchaintransactions 32 a according to the proof-of-work (“PoW”) target scheme34 a that is specified by the blockchain environment 22 a, theblockchain network server 28 a, and/or the blockchain network 260 a. Theminer system 22, however, may also participate in the blockchainenvironment 22 b and mine the blockchain transactions 32 b sent from theblockchain network server 28 b to authorized miners in blockchainnetwork 260 b. The miner system 22 may thus mine the blockchaintransactions 32 b according to the proof-of-work (“PoW”) target scheme34 b that is specified by the blockchain environment 22 b, theblockchain network server 28 b, and/or the blockchain network 260 b.Because exemplary embodiments require no specialized GPU or ASIC, theminer's conventional CPU 36 may be adequate for mining operations inboth blockchain environments 22 a and 22 b. The miner system 22 may thusdownload, store, and execute the client-side blockchain mining softwareapplication 196 a that is required to mine the blockchain transactions32 a in the blockchain environment 20 a. The miner system 22 may alsodownload, store, and execute the client-side blockchain mining softwareapplication 196 b that is required to mine the blockchain transactions32 b in the blockchain environment 20 b. The miner system 22 may thuscall, execute, coordinate, or manage the encryption algorithm 46 a, thedifficulty algorithm 48 a, and/or the proof-of-work (“PoW”) algorithm 52a according to the proof-of-work (“PoW”) target scheme 34 a specified bythe blockchain environment 20 a. The miner system 22 may also call,execute, coordinate, or manage the encryption algorithm 46 b, thedifficulty algorithm 48 b, and/or the proof-of-work (“PoW”) algorithm 52b according to the proof-of-work (“PoW”) target scheme 34 b specified bythe blockchain environment 20 b. Because exemplary embodiments requireno specialized GPU or ASIC, the miner system 22 has the hardwareprocessor capability and performance (e.g., clock speed, processorcore(s)/thread(s) count, cycles, the on-board cache memory 100, thermalprofile, electrical power consumption, and/or chipset) to mine in bothblockchain environments 20 a and 20 b. The miner system 22 mayparticipate in multiple blockchain environments 20, thus having thecapability to earn additional rewards, while also being less expensiveto purchase and to operate.

FIGS. 42-43 illustrate virtual blockchain mining, according to exemplaryembodiments. Because the miner system 22 may be agnostic to theblockchain environment 20, the miner system 22 may outsource orsubcontract mining operations to a virtual machine (or “VM”) 262. Forexample, the miner system 22 may implement different virtual machines262, with each virtual machine 262 dedicated to a particular blockchainenvironment 20. The miner system 22, for example, may assign the virtualmachine 262 a to mining the blockchain transactions 32 a sent from theblockchain network server 28 a. The miner system 22 may assign thevirtual machine 262 b to mining the blockchain transactions 32 b sentfrom the blockchain network server 28 b. The miner system 22 may thus bea server computer that participates in multiple blockchain environments20 and potentially earns multiple rewards. The miner system 22 mayprovide virtual mining resources to multiple blockchain environments 20,thus lending or sharing its hardware, computing, and programmingresources. While FIG. 42 only illustrates two (2) virtual machines 262 aand 262 b, in practice the miner system 22 may implement any number orinstantiations of different virtual machines 262, with each virtualmachine 262 serving or mining one or multiple blockchain environments20. So, when the miner system 22 receives the blockchain transactions32, the miner system 22 may inspect the blockchain transactions 32 forthe proof-of-work (“PoW”) target scheme 34 that identifies thecorresponding encryption, difficulty, and PoW scheme (such as byconsulting the databases 70, 74, and 78, as above explained). The minersystem 22 may additionally or alternatively inspect the blockchaintransactions 32 for the identifiers 200, 210, 214, and 250 (as thisdisclosure above explains). Once the blockchain environment 20 isdetermined, the miner system 22 may then

FIG. 43 illustrates a database lookup. When the miner system 22determines the PoW scheme 34 and/or any of the identifiers 200, 210,214, and 250, the miner system 22 may identify the corresponding virtualmachine 262. For example, the miner system 22 may consult an electronicdatabase 264 of virtual machines. While the database 264 of virtualmachines may have any structure, FIG. 43 illustrates a relational table266 having entries that map or associate the PoW scheme 34 and/or any ofthe identifiers 200, 210, 214, 250 to the corresponding virtual machine262. The miner system 22 may thus query the electronic database 264 ofvirtual machines for any of the PoW scheme 34 and/or any of theidentifiers 200, 210, 214, 250 and determine the corresponding virtualmachine 262. Once the virtual machine 262 is identified (e.g., a memoryaddress or pointer, processor core, identifier, network address and/orservice provider, or other indicator), the miner system 22 may assignthe blockchain transactions 32 to the virtual machine 262 for mining.

The miner system 22 may thus serve many blockchains. The miner system22, for example, may mine BITCOIN® and other cryptographic cointransactional records. However, the miner system 22 may also nearlysimultaneously mine financial records sent from or associated with afinancial institution, inventory/sales/shipping records sent from aretailer, and transactional records sent from an online website. Theminer system 22 may participate in multiple blockchain environments 20,thus having the capability to earn additional rewards, while also beingless expensive to purchase and to operate.

FIG. 44 is a flowchart illustrating a method or algorithm for mining theblockchain transactions 32, according to exemplary embodiments. Theinputs 24 (such as the blockchain transactions 32) may be received(Block 300). The proof-of-work (“PoW”) target scheme 34 may be received(Block 302). The message 202 may be received (Block 304). Theidentifiers 200, 210, 214, and/or 250 may be received (Block 306). Theblock 40 of data may be generated (Block 308). The encryption algorithm46 (such as the hashing algorithm 54) may be identified (Block 310) andthe output 56 (such as the hash values 60) may be generated byencrypting/hashing the blockchain transactions 32 and/or the block 40 ofdata (Block 312). The encryption/hashing service provider 150 may beidentified and the blockchain transactions 32 and/or the block 40 ofdata outsourced (Block 314). The output 56 (such as the hash values 60)may be received from the encryption/hashing service provider 150 (Block316). The difficulty algorithm 48 may be identified (Block 318), thedatabase table 90 may be generated or identified, and the difficulty 50may be generated by executing the difficulty algorithm 48 (Block 320).The difficulty service provider 156 may be identified and the difficultycalculation outsourced (Block 322). The difficulty 50 may be receivedfrom the difficulty service provider 156 (Block 324). The PoW algorithm52 may be identified (Block 326), the database table 90 may be generatedor identified, and the PoW result 42 determined by executing the PoWalgorithm 52 (Block 328). The PoW service provider 120 may be identifiedand the PoW calculation outsourced (Block 330). The PoW result 42 may bereceived from the PoW service provider 120 (Block 332). The output 56(such as the hash values 60), the difficulty 50, and/or the PoW result42 may be compared to the PoW target scheme 34 (Block 334).

Exemplary embodiments may win the block 40 of data. If the output 56,the difficulty 50, and/or the PoW result 42 satisfy the PoW targetscheme 34, then the miner system 22 may submit the output 56, thedifficulty 50, and/or the PoW result 42 to the blockchain network server28. The miner system 22 may itself determine if the miner system 22 isthe first to satisfy the PoW target scheme 34, or the miner system 22may rely on the blockchain network server 28 to determine the firstsolution. When the miner system 22 is the first solver, the miner system22 earns the right to add the block 40 of data to the blockchain 64.However, if the PoW target scheme 34 is not satisfied, the miner system22 implements a change or modification and repeats.

FIG. 45 is a schematic illustrating still more exemplary embodiments.FIG. 45 is a more detailed diagram illustrating a processor-controlleddevice 350. As earlier paragraphs explained, the miner system 22 may beany home or business server/desktop 160, laptop computer 162, smartphone164, tablet computer 166, or smartwatch 168, as exemplary embodimentsallow these devices to have adequate processing and memory capabilitiesto realistically mine and win the block 40 of data (as explained withreference to FIG. 18). Moreover, exemplary embodiments allow anyCPU-controlled device to realistically, and profitably, process theblockchain transactions 32, thus allowing networked appliances,radios/stereos, clocks, tools (such as OBDII diagnostic analyzers andmultimeters), HVAC thermostats and equipment, networkswitches/routers/modems, and electric/battery/ICU engine cars, trucks,airplanes, construction equipment, scooters, and other vehicles 170.

Exemplary embodiments may be applied to any signaling standard. Mostreaders are familiar with the smartphone 164 and mobile computing.Exemplary embodiments may be applied to any communications device usingthe Global System for Mobile (GSM) communications signaling standard,the Time Division Multiple Access (TDMA) signaling standard, the CodeDivision Multiple Access (CDMA) signaling standard, the “dual-mode”GSM-ANSI Interoperability Team (GAIT) signaling standard, or any variantof the GSM/CDMA/TDMA signaling standard. Exemplary embodiments may alsobe applied to other standards, such as the I.E.E.E. 802 family ofstandards, the Industrial, Scientific, and Medical band of theelectromagnetic spectrum, BLUETOOTH®, low-power or near-field, and anyother standard or value.

Exemplary embodiments may be physically embodied on or in acomputer-readable storage medium. This computer-readable medium, forexample, may include CD-ROM, DVD, tape, cassette, floppy disk, opticaldisk, memory card, memory drive, and large-capacity disks. Thiscomputer-readable medium, or media, could be distributed toend-subscribers, licensees, and assignees. A computer program productcomprises processor-executable instructions for processing or mining theblockchain transactions 32, as the above paragraphs explain.

While the exemplary embodiments have been described with respect tovarious features, aspects, and embodiments, those skilled and unskilledin the art will recognize the exemplary embodiments are not so limited.Other variations, modifications, and alternative embodiments may be madewithout departing from the spirit and scope of the exemplaryembodiments.

1. A method of deterring a specialized hardware processor in ablockchain environment, comprising: receiving, by a central processingunit (CPU) operating in a miner system, a proof-of-work target schemeassociated with the blockchain environment; receiving, by the CPUoperating in the miner system, a blockchain transaction associated withthe blockchain environment; identifying, by the CPU operating in theminer system, a proof-of-work service provider that provides aproof-of-work service; mining, by the CPU operating in the miner system,the blockchain transaction by outsourcing the blockchain transaction viaa packetized communications network to the proof-of-work serviceprovider that provides the proof-of-work service; and receiving, by theCPU operating in the miner system, a service result of the proof-of-workservice via the packetized communications network; wherein theoutsourcing of the blockchain transaction deters the specializedhardware processor in the blockchain environment.
 2. The method of claim1, further comprising identifying a hashing algorithm that is associatedwith the proof-of-work target scheme.
 3. The method of claim 2, furthercomprising generating a hash value by hashing the blockchain transactionusing the hashing algorithm.
 4. The method of claim 3, furthercomprising sending the hash value via the packetized communicationsnetwork to the proof-of-work service provider that provides theproof-of-work service.
 5. The method of claim 1, further comprisingcomparing the service result of the proof-of-work service to theproof-of-work target scheme associated with the blockchain environment.6. The method of claim 1, further comprising receiving a difficulty viathe packetized communications network as the service result of theproof-of-work service.
 7. The method of claim 6, further comprisingcomparing the difficulty to the proof-of-work target scheme associatedwith the blockchain environment.
 8. The method of claim 1, furthercomprising receiving a proof-of-work result via the packetizedcommunications network as the service result of the proof-of-workservice.
 9. The method of claim 8, further comprising comparing theproof-of-work result to the proof-of-work target scheme associated withthe blockchain environment.
 10. A miner system for mining a blockchaintransaction associated with a blockchain environment, comprising: acentral processing unit; and a memory device storing instructions that,when executed by the central processing unit, perform operations,comprising: receiving a proof-of-work target scheme associated with theblockchain environment; receiving the blockchain transaction associatedwith the blockchain environment; identifying a proof-of-work serviceprovider that provides a proof-of-work service; mining the blockchaintransaction by outsourcing the blockchain transaction via a packetizedcommunications network to the proof-of-work service provider thatprovides the proof-of-work service; and receiving a service result ofthe proof-of-work service via the packetized communications network;wherein the outsourcing of the blockchain transaction deters the miningof the blockchain transaction using an application-specific integratedcircuit.
 11. The miner system of claim 10, wherein the operationsfurther comprise identifying a hashing algorithm that is associated withthe proof-of-work target scheme.
 12. The miner system of claim 11,wherein the operations further comprise generating a hash value byhashing the blockchain transaction using the hashing algorithm.
 13. Theminer system of claim 12, wherein the operations further comprisesending the hash value via the packetized communications network to theproof-of-work service provider that provides the proof-of-work service.14. The miner system of claim 10, wherein the operations furthercomprise comparing the service result of the proof-of-work service tothe proof-of-work target scheme associated with the blockchainenvironment.
 15. The miner system of claim 10, wherein the operationsfurther comprise receiving a difficulty via the packetizedcommunications network as the service result of the proof-of-workservice.
 16. The miner system of claim 15, wherein the operationsfurther comprise comparing the difficulty to the proof-of-work targetscheme associated with the blockchain environment.
 17. The miner systemof claim 10, wherein the operations further comprise receiving aproof-of-work result via the packetized communications network as theservice result of the proof-of-work service.
 18. The miner system ofclaim 17, wherein the operations further comprise comparing theproof-of-work result to the proof-of-work target scheme associated withthe blockchain environment.
 19. A memory device storing instructionsthat, when executed by a central processing unit, perform operationsthat mine a blockchain transaction associated with a blockchainenvironment, the operations comprising: receiving a proof-of-work targetscheme associated with the blockchain environment; receiving theblockchain transaction associated with the blockchain environment;identifying a proof-of-work service provider that provides aproof-of-work service; mining the blockchain transaction by outsourcingthe blockchain transaction via a packetized communications network tothe proof-of-work service provider that provides the proof-of-workservice; and receiving a service result of the proof-of-work service viathe packetized communications network; wherein the outsourcing of theblockchain transaction deters the mining of the blockchain transactionusing an application-specific integrated circuit.
 20. The memory deviceof claim 18, wherein the operations further comprise comparing theservice result to the proof-of-work target scheme associated with theblockchain environment.